QB64 Phoenix Edition 3.4.1 Released

[SMcNeill]

the new file opening system does not match the look of the qb64pe editor. under linux there is a latency of about 1 second before the window appears. apparently the problems found under linux have not been corrected. i think i'll use version 0.50 again.

There's problems under Linux?   If so, I can testify that they haven't been corrected yet, as so far, they haven't even been reported to us.  It's hard to fix what you don't know is broken. 

If you find a glitch, kindly post an issue on the problem over at our github so someone can take a look at it.  The Linux IDE has always been a little slow and unresponsive, so I don't know if this "one second latency" is just something associated with the IDE, or if it's with the new Open Dialog library itself.  

Of course, you're always welcome to keep using 0.5.  It's nice to see that we met all your programming needs so early in our endeavors!  Here at the Phoenix Edition, we try and offer something for everybody -- I'm happy you've found what you like out of what we offer! 

[DSMan195276]

Looks like the Open Dialog always starts where you last opened a file.

Is there a way to start in a set Folder? My Shortcut Properties Startup Folder no longer works.

_OpenFileDialog$

does actually have support for opening in a particular folder, QB64-PE just isn't passing it. I just tested it and we can likely fix that in the next release so that it opens to whatever folder you started QB64-PE from.

For the Save dialog, we already have 

_SaveFileDialog$

support so we can definitely do it. It was looking a bit complicated to change though and we wanted to get the fixes for the all the dialog stuff out so we opted to skip it for now.

[mnrvovrfc]

How long does it take for one of you to be able to use Windows right after typing password and confirming?

It could take longer on Linux. A lot longer, I don't care if someone has 16 cores and 1TB RAM, the latest graphics gear and drivers and so on. No I don't recommend "auto-log-in" to make it faster. The desktop/window environment doesn't matter. IJS LOL.

What about having to get out of "Recent Files" to navigate to a certain folder? Sure but with the old open file dialog in QB64PE IDE it could take longer fumbling with keyboard and/or mouse.

It doesn't bother me, as I've already said. In fact, it's good to have both options now, making the IDE look like a modern program that appeals to people.

_OpenFileDialog$

does actually have support for opening in a particular folder, QB64-PE just isn't passing it. I just tested it and we can likely fix that in the next release so that it opens to whatever folder you started QB64-PE from.

For the Save dialog, we already have 

_SaveFileDialog$

support so we can definitely do it. It was looking a bit complicated to change though and we wanted to get the fixes for the all the dialog stuff out so we opted to skip it for now.

This is good news indeed. I brought up the point about the text editor's save-file dialog offering only two choices, "Text Files" or "All text files" because I have to use Pluma/xedit. There are many editors for Linux, but few of them are good. Scintilla looks pretty but is a PITA, it's easy to fall into a hole configuring it to be just right. No editor based on Scintilla seems to have fixed the serious focus problem, in which some cases another program is opened then closed and then the user wants to get back to reading or editing but the stupid thing expects a mouse click inside its editing area. No keystroke shortcut works because the editor doesn't think it has the focus. Most of the editors are good for editing Python source code but never for a text entry like in this forum, more proper for a word processor. I cannot completely keep out Libreoffice because of it.

BTW do not install Notepad++ (NPPP) via Microsoft Store... it's intolerably slow, and the only good thing it has is "dark mode." For someone who must have that program, please download it from the author's site.

[Coolman]

the new file opening system does not match the look of the qb64pe editor. under linux there is a latency of about 1 second before the window appears. apparently the problems found under linux have not been corrected. i think i'll use version 0.50 again.

There's problems under Linux?   If so, I can testify that they haven't been corrected yet, as so far, they haven't even been reported to us.  It's hard to fix what you don't know is broken. 

If you find a glitch, kindly post an issue on the problem over at our github so someone can take a look at it.  The Linux IDE has always been a little slow and unresponsive, so I don't know if this "one second latency" is just something associated with the IDE, or if it's with the new Open Dialog library itself.  

Of course, you're always welcome to keep using 0.5.  It's nice to see that we met all your programming needs so early in our endeavors!  Here at the Phoenix Edition, we try and offer something for everybody -- I'm happy you've found what you like out of what we offer! 

https://staging.qb64phoenix.com/showthre...87#pid8987

https://staging.qb64phoenix.com/showthre...57#pid9057

https://staging.qb64phoenix.com/showthre...66#pid9066

https://staging.qb64phoenix.com/showthre...63#pid9163

[SMcNeill]

Ahhh..  One set of commands that have a known workaround is glitched.  There's a race condition which occurs with screen handles when QB64 first starts and runs.  It's been in the language forever and ever, and writing a fix into the language isn't something that's as trivial as a walk in the park.  This same style issue has been reported ever since version QB64 version 0.954 -- the last SDL version before Galleon swapped over to OpenGL for QB64 -- and the solution is always the exact same as you posted in a few places yourself:   https://staging.qb64phoenix.com/showthread...57#pid9057

Just add a _DELAY at the start of the program and give the OS time to finish registering the handles properly, before trying to do anything with them.

The issue is a race condition which, like almost all race conditions, has unpredictable outcomes when ran.  IF the system OS is running slow due to background processes, the qb64 program wins the race and runs properly.  If the qb64 program is running fast as the OS might give it priority as a new process, then the program glitches.

v0.5, which you mention, is still plagued by this race problem.  Nothing has changed between then and the latest version to introduce the issue into the language.  So *why* does 0.5 work for you and 3.4.1 not??  It's impossible to say.  Code we cleaned up might compile and run one nanosecond faster under the newest version.  Or maybe it was swapping in the newer audio and image libraries.  Whatever the cause, the end result is that 3.4.1 is running a weeeeeee bit faster at the initial startup phase, and thus it's hitting that race condition and glitching out more often than the 0.5 version is.  

Now note -- that's not to say that the 0.5 version *won't* glitch out, at all!  It's just that it's slower, so it's going to glitch out less often.  That's just the nature of how race conditions work.

So what can one do about it??

Well, they could always code in COBOL or some such and avoid the issue completely.  OR, they could wait for the devs to finally correct the issue, and not code anything at all until then.  (I wouldn't hold my breath on this point, as this style race condition has been around for at least the last 10 years in the language.  Here's a link to the exact same issue, and exact same solution, being discussed 5 years ago at the old forums: Occassional Graphical Glitch (alephc.xyz).)  OR, you can just add a _DELAY to the start of any program that requires a window handle early in its creation.

Sticking with v0.5 won't solve the issue for you.  At best, it'll be a bandaid that lets the program run on your specific computer.  Share the code elsewhere, and others will have unpredictable results due to how fast/slow their PC performs against the compiled exe.  OS wins the race, all is good.  QB64 program run fast, it glitches trying to access a handle that the OS hasn't registered yet.

That's the issue, and the options, in a nutshell, for what's going on with the code you linked to. 

[Coolman]

i understand your point of view. that said, you say that this problem has been known for many years. if there is no solution and if it depends on the computer used, how to guess the ideal parameter in the delay command in case the distributed program will run on different slow, fast or very fast computers. the problem should be fixed in the source code, not fixing it exposes to future problems. the link you provided is interesting because it confirms that it happens with other commands than _DESKTOPWIDTH and _DESKTOPHEIGHT...

finally, the fact that it works with qb64 v0.5 and not 3.4.0 and 3.4.1 on the same machine proves that there was a regression somewhere in the code...

Well, I'll deal with it for now. Thanks for your explanations.

[mnrvovrfc]

the problem should be fixed in the source code, not fixing it exposes to future problems. the link you provided is interesting because it confirms that it happens with other commands than _DESKTOPWIDTH and _DESKTOPHEIGHT...

The "problem" really is that people want to use budget laptops and high-end gaming computers, and everything else in between. For Windows, there was a nice, easy solution provided by the makers of OS. But for Linux...

I'm not saying you are wrong or anybody else trying QB64(PE) and dealing with inconsistent behavior, and desiring the same thing on Linux or MacOS that was experienced on Windows. But right now this issue has to do with how the OS is designed. ApCo and M$ have to get it right, at any cost (including spying on neighbors) and it must be snappy, because they have to make money out of it, it's part of the "American Dream." I don't like this "inequality" between Windows and Linux, but it doesn't bother me.

You said you use KDE Neon right? But what about someone who has a different desktop/window manager? Say GNOME, or Cinnamon, or that Awesome WM that I should like because I could fix things up with Lua?

Anyway this "problem" is insignificant for somebody who only cares about putting an integer 13 or less right after "SCREEN" to get a graphics screen. Ho ho do a "SCREEN 13" on one of today's viewports. "But that's all?" or "What the fork it's too small!" or some other interjection is always an interesting reaction. It comes from people who have never seen an AT&T terminal before Mr. Torvalds gave the world an incredible gift.

Yeah just use a number with "SCREEN" instead of "_NEWIMAGE()" then. Things are different when somebody wants 1920x1020 or something like that, or much larger, then complains the text is "too tiny." This "problem" is going to remain until more people move on to the super-large screens and computers that right now cost USD2000. Very unlikely that's going to happen. Also you have to think about users on older versions of Windows which are 32-bit, and are also running 16-bit software they're not interested in giving up only for any small fix they might not be interested in.

How long does it take you to log in? I mean, after you give your username and password, then confirm, then you see the desktop? For me on Ubuntu Studio, with the 10-year-old portable computer with slow HDD that I have it took a good deal of a minute. I soon got tired of "Ubuntu Studio" written in large letters and the gear that wasn't even spinning all the time I was waiting for it to load. Sometime later I put in Manjaro KDE. That took about half the time but still, it was ten seconds or so. How long did I have to wait until Solus MATE desktop, or Manjaro MATE desktop? Almost 30 seconds for some reason, from that HDD.

Therefore I don't mind waiting a few seconds until any dialog pops up out of this programming system. Because before QB64PE v3.4.0 it was either "xmessage" or "do-it-yourself"...

[SMcNeill]

i understand your point of view. that said, you say that this problem has been known for many years. if there is no solution and if it depends on the computer used, how to guess the ideal parameter in the delay command in case the distributed program will run on different slow, fast or very fast computers. the problem should be fixed in the source code, not fixing it exposes to future problems. the link you provided is interesting because it confirms that it happens with other commands than _DESKTOPWIDTH and _DESKTOPHEIGHT...

finally, the fact that it works with qb64 v0.5 and not 3.4.0 and 3.4.1 on the same machine proves that there was a regression somewhere in the code...

Well, I'll deal with it for now. Thanks for your explanations.

It may be frustrating that it doesn't work as you'd like, but here's the basic process and the error at large:

Code: (Select All)

Declare Library
    Function glutGet& (ByVal what&)
End Declare

Sleep

Print glutGet(200)
Print glutGet(201)

Compile and run.  You'll get your desktop width and height back directly from glutget.

Remark out that Sleep statement.  Compile and attempt to run...

This isn't a glitch that's built into QB64 itself; it's a glitch built into one of the core libraries that QB64 is built upon.  glut should wait until after everything is initialized before it tries to call these handles -- it doesn't.  

So, what do we do with such an issue?  Try and patch the version of freeglut that we're using?  Does its license even allow for that??  Does anyone have the expertise to go into freeglut's core and sort out what the issue with their threading is, and apply a fix for it??

For Windows, we chose to skip the glutGet call completely, in the case for _DESKTOPHEIGHT and _DESKTOPWIDTH.  Instead, we use the windows API to get those values, thus we never have the issue to begin with.

Now, on Linux, in its dozens of varieties, what could we call to get that same information, without relying on glut?  Does X11 report it somewhere?  

I dunno!  I'm not a Linux programmer.  I'm not familiar with the Linux system.  I may know what the issue is -- just like you do now as well -- but that doesn't mean I'm any more capable of fixing it than you are. 

It is what it is.  Until someone steps up who's willing to redo the freeglut backend (maybe someone will swap GLEW in for us instead), or who knows enough to work around the issue with freeglut, we're stuck with it -- just the same as we have been for years now.

Not all bugs get fixed the day they're reported, no matter how much both the developers and the user base might wish they did.

[mnrvovrfc]

Now, on Linux, in its dozens of varieties, what could we call to get that same information, without relying on glut?  Does X11 report it somewhere?  

I dunno!  I'm not a Linux programmer.  I'm not familiar with the Linux system.  I may know what the issue is -- just like you do now as well -- but that doesn't mean I'm any more capable of fixing it than you are. 

At least there's "xrandr" terminal command. The first entry which says "connected" rather than "disconnected" should give out the maximum dimensions. But this has to be tested with two screens. Also the "library" version might be preferred, not another thing to have to "SHELLHIDE" to. In fact enter "man 3 xrandr" on the terminal.

I almost forgot to mention there's this new craze called "Wayland" going around to replace "X11" which would of course have a different way of reporting its state.

Here's the output on my laptop from Manjaro MATE:

Code: (Select All)

[xx@hp2000pc ~]$ xrandr
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1366x768      60.03*+  40.01  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   640x400       59.88    59.98  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

[PhilOfPerth]

To quote, "The new file opening system does not match the look of the qb64pe editor. under linux there is a latency of about 1 second before the window appears."
Oh dear! That could seriously eat into your time! 
It feels like, as my grandpa once wrote in one of his plays, "Much ado about nothing".
When I think back to tape-loading days, when just loading the programme to be used could take up to 10 minutes, I realize how far we've (you've) come.
I know, we still want to improve, but, to use a spoonerism, "don't pet the sweaty stuff, and don't sweat the petty stuff"!