11-19-2022, 04:48 PM
(11-19-2022, 09:11 AM)Coolman Wrote: the latency problem I found is probably due to the detection. for example, I use kdialog often in scripts and it doesn't take about a second to run, example for kde, type in command line :Again you're demonstrating you know about only one D.E. and know about it well, much better than everybody else in this forum. This is something that will not work on any Linux installation that has nothing from KDE. Maybe it would work in XFCE with KDE stuff installed... but why do I want a "fat" open file dialog that looks like Dolphin away from Plasma? :O
kdialog --getopenfilename ~
it's practically instantaneous.
Nobody likes being stuck adjusting system settings regularly only to make it run faster. One that is knowledgeable, a Linux expert could get away with it regularly. But that's like 1% of the population of users of personal computers. Somebody else with deep knowledge of Macintosh or Windows could be the same way. But with Linux is harder because there are different mixes of the same thing.
You didn't answer my question about logging in, because that might take much longer than one second. It cannot bother me, because I choose to put a few installed distros onto pluggable USB disks to check them out. I cannot "virtual box." I don't like live distros and even less now with persistence after checking out AV Linux and its leaving such a bad impression. In addition I tried "Liveslak DAW" and it was a mother to have to copy it to another USB drive only to be able to get persistence... but that must have been a limitation of Ventoy.
On at least one external USB disk I could start up faster than I could with the built-in HDD of my laptop. But that still takes some time, at least 30 seconds from turning on computer to being able to use the desktop. That's what I meant in my previous post.
Maybe on QB64(PE) earlier than v3.4 you could change the "libqb.cpp" to use "kdialog" instead of "xmessage", to fake the call to "MessageBox" function that was originally meant for Windows API. It's not as hard as it looks; I adjusted it previously so it used "zenity".
The fix has to be as universal as possible on Linux, it cannot depend on anything KDE, GNOME, XFCE etc. installed. Because the QB64PE developers decided to bypass "freeglut" on Windows to get the desktop width and height, I think an attempt should be made on Linux to check if X11 is in place, and then at least call "xrandr" command-line program or some other scheme. It might not solve the race condition that Steve described. Also the problem would remain, having to wait for "SCREEN _NEWIMAGE()" with much larger dimensions than old VGA.