POTENTIAL BREAKING CHANGES

[DualBrain]

I was going to call this discussion "Course Correction" - but the reality is there are two types of course correction; those that add incomplete/missing functionality and those changes that will have to break existing functionality in order to attain the desired overall goal(s) of "What is QB64?" where the first guideline is "How does it work in QBasic/QB45?" Obviously, everything can't work in the same way as QBasic/QB45; but every effort should be made to try.

Any breaking changes need to be considered carefully and with extreme caution; possibly offering configuration options (maybe) and definitely being very clearly documented not only to the change but the underlying reason(s) as to why.

This discussion is about weighing the pros/cons to any potential consideration.

[DualBrain]

To get the ball rolling, it appears that qb64.exe will automatically change the working path to the path of the qb64.exe executable. I feel like this is problematic in that the code you write may want to affect files in the current path (where you were at the command line). Having to CHDIR _STARTDIR$ is certainly a valid work around to this issue; but if memory serves me the behavior of QBasic/QB45 would maintain the working path; not change the working path to the location of the qbasic.exe/qb.exe.

[Statsman1]

The evolution of anything occasionally requires paradigm shifts cataclysmic in nature.

Or, put another way, if it is imperative for something to work, and can be made to work within QB64 despite not working, or not even available, in QBasic or 45, then making it work is, to me, more important than maintaining genetic purity.

I appreciate the desire to stick to the OG wherever possible, but "Sorry, QBasic didn't do that." just doesn't fly with me, when the solution can be found.

[DualBrain]

I think the close button in the Help window is a good example:

The desire is to have a means to close the pane using the mouse. What is the best way to do this? Is it a bright red X; where the color doesn't match anything, anywhere within the application? That doesn't really make sense. Is it an X? Is it an arrow? QB/QB45 does have arrows that manipulate the panes... so couldn't that paradigm continue to work? If not, why? If so, would it make sense to change it to "something else" (for the sake of changing it, no other reason)?

All of this is to say that we have something pretty clear that we can base all of our future decisions upon; however, it is also clear that some decisions were made that are either flying in the direct face of this (which can cause a disjointed set of features) and/or outright incomplete/missing when compared to what was available in QBasic/QB45. In other cases, features were added that, although are completely new but somewhat fit in the style of what came before, they too are incomplete (status bar color, I'm looking at you.)

Switching back to the Help pane... what reasoning (at this point probably won't have an answer) was there for putting it at the bottom of the screen instead of where it was to begin with? Regarding panes in general, why weren't the pane management features implemented? In other words, why am I stuck with the Status pane always being visible?

To attack this from another point of view, it is nice that "scroll bars" have been added - QBasic/QB45 don't have these. However, when we have a blank document... why are the scroll bars even visible? Comparing between the new and old I'm of the opinion that the scroll bars are a nice addition, but the fact that they are always visible does create a bit of "screen noise" - shouldn't they be visible if there's something to actually scroll - if no scrolling necessary, then have these revert to the "thin line" that there used to be.

Again, nothing is to say that new features/capabilities won't be added; it's just that more work needs to go into designing these as there is this lineage that needs to be respected. And, unfortunately, it does appear that some things were done where they were done without any regard to this history/foundation.

In the end, things should feel like a natural progression from then to now; saying that, there are certainly areas that are lacking, others that are missing and others that are questionable - those that are questionable, I'm making it clear that it is not only OK to question but the questioning is encouraged. Upon doing so, let's discuss it further as I believe each one of these deserves to be weighed upon their own individual merits.

The baseline answer is "how did it work before QB64?" and that the conversation starts there.

Regarding the default working folder (as an example), I suspect that QB64 does it the way it does it currently (which is very different than QBasic/QB45) for the sake of QB64 and not for the purposes/benefit of the coders that are consuming QB64. I say this as there is seems to be other areas of QB64 that lean on this behavior and even the documentation to suggest this to be the case. ;-)