Feature parity for win32 version

hgy29

@MoKaLux, you were on the right track. I Have updated my repo with a working get("directory")

MoKaLux

I got openFileDialog appearing and it returns the path to the chosen file . Now I have to find how to pass the arguments title|path|extensions
Here is the working and tested code I have so far: https://wiki.gideros.rocks/index.php/CPlusPlus_for_Gideros_Studio_Help#openFileDialog

Viva Gideros and C++

EDIT: I can now filter file extensions but it is hard coded, how do I get them from Gideros?

MoKaLux

some more progress:
application:get(openFileDialog(title|path|extensions//help))

I can now set the open dialog name passed via gideros (title), that was easier than I thought but now the hard stuff: how to set the extensions (not done) and the starting folder (done) via gideros
The good news is that application:get(saveFileDialog(title|path|extensions//help)) should now be easy to implement!?

Questions: hgy29 do you think I can push my code so far? if so where is the best place official Gideros GH or hgy29 GH?

Thank you

hgy29

Hi @MoKaLux, I have merged your last code with gideros, and completed it, now win32 fully support all three file dialogs on win32, including extensions. Thanks for your help, it saved me a lot of time.

MoKaLux

I have merged ... and completed it, now win32 fully support all three file dialogs on win32, including extensions. Thanks for your help, it saved me a lot of time.

I am happy this helped , thank you for coding the hardest parts

I am sorry but I have 2 more issues :
- I cannot make os.execute work
- I cannot make lfs work

os.execute("start ".."c:\\tmp") -- "c:/tmp" "c:/tmp/" "c:\\tmp\\" -- NOT WORKING BUT NO CRASH

lfs = require "lfs" -- OK ... print(application:get("directory", "pictures")) -- OK lfs.chdir(application:get("directory", "pictures")) --> CRASHES THE APP :-(

Questions: where do I find os.execute in gideros code (GH)? I couldn't find it

Thank you

rrraptor

MoKaLux said:

Questions: where do I find os.execute in gideros code (GH)? I couldn't find it

Probably here
https://github.com/gideros/luau/blob/c8ce3ce30c030eb55db043fea0dd4de91a805f81/VM/src/loslib.cpp#L117

MoKaLux

rrraptor said:

Probably here
https://github.com/gideros/luau/blob/c8ce3ce30c030eb55db043fea0dd4de91a805f81/VM/src/loslib.cpp#L117

In this case I prefer not to touch it since it is Luau source file

keszegh

good job guys, thanks for the progress

hgy29

MoKaLux said:

In this case I prefer not to touch it since it is Luau source file

Don't worry, it is Gideros fork of luau.
I made the change anyway:
https://github.com/gideros/luau/commit/8db99f44c6e833be229c3d1e846ae1cb62dee2d8

MoKaLux

I tried updating to latest lfs 1.8 https://github.com/lunarmodules/luafilesystem. I copied the new 1.8 lfs lfs.cpp and lfs.h files into gideros \Build.Win\All Plugins\lfs\source, I didn't touch anything, only copy/paste and that worked on export for windows 64 and Gideros player NOT SO SURE ABOUT THIS! NEED MORE TESTS

I found some internet links that may explain the issue but I hoped that would work with lfs 1.8

win32 LFS problem with separator

Recent changes to path handling (most likely [0]) caused AssetCatalogTest.create_catalog_after_loading_file to fail on WIN32.

The test relied on the resulting path to be joined with "/" as a path separator. The resulting path used both forward and back-slashes. While these do work for some API's on WIN32, mixing both in a file path isn't expected behavior in most cases, so update the tests to use native slash direction for file-paths.

PS: I have a feeling new Gideros is coming

PS2: a screenshot

I don't know if the capture happens before the crash or after the crash so I am not sure if callFile is the actual culprit

Still trying, Viva Gideros c++

hgy29

I couldn't reproduce the crash,

os.execute("start ".."c:\\tmp")

works for me.

MoKaLux

(at) hgy29, I know os.execute now works because you did it (not me )

I don't know if your comment is related to my last one, but I am trying to make lfs works with win32 having quite a hard time doing it

MoKaLux said:

I am sorry but I have 2 more issues :
- I cannot make os.execute work HGY29 FIXED IT
- I cannot make lfs work

lfs = require "lfs" -- OK ... print(application:get("directory", "pictures")) -- OK lfs.chdir(application:get("directory", "pictures")) --> CRASHES THE APP :-(

hgy29

lfs.chdir works here too

hgy29

could it be because your user directory contains non Latin1 characters ? Mine is purely ASCII

MoKaLux

I am sorry to insist but that doesn't work on my machine windows 10 export to win32
My code:

lfs = require "lfs" local picdir = application:get("directory", "pictures") -- OK print("* picture directory *:", picdir) -- tests print("* lfs.currentdir() *: ", lfs.currentdir()) -- OK lfs.chdir(picdir) -- CRASH

The win32 console output without lfs.chdir(picdir):

* picture directory *: C:\Users\mokat\Pictures * lfs.currentdir() *: C:\X_MOKA\PROJECTS\_gideros\_BUILDS\win32\PLATFORMER_CBUMP_TECS_20221101

gideros studio debug output:

C:/Users/mokal/Pictures C:\dev\gideros20221103\Build.Win

Notice the difference between the separators!. That maybe the issue?

AFAIK there is no non Latin characters and there are no spaces as well
I am glad it is working for you.
Could I have more people to try on their machines please?

MoKaLux

various win32 fixes (awaiting on GH)

platform-win32.cpp:
- getKeyboardModifiers were still activated after keyup events: fixed (tested ok)
- added strcmp(what, "mkDir") (tested ok)
- auto add extension to saved files

win32.cpp:
- mouse wheel had a * 120 which resulted in delta of 14400 (120 * 120): fixed (tested ok)
- add missing ALT modifier to various mouse events (not tested yet)

imho it is important to get win32 working as close as x64 as possible. I learned the hard way Qt license for x64 is very limited or very expensive

Now I can port my Qt app to a win32 build and make millions thanks to gideros, then I may buy their Qt licence donate to Gideros.

Viva Gideros

MoKaLux

In win32 when I open a windows file dialog box and drag it around, the mouse position (captured via mousemove event, e.x, e.y) changes meaning the mouse event are propagated through the file dialog. This doesn' t happen under Gideros Player nor when exported to x64 (Qt).

Do you know where I can fix this please ?

EDIT: would it be hard to not use Qt for x64 builds? Do we have to make changes like these for all the windows 64 functions? Am I being naïve?

}else if (strcmp(what, "pathfileexists") == 0) // new 20221116 XXX { int m = 0; // modes: 0=Existence only, 2=Write-only, 4=Read-only, 6=Read and write if (args.size() >= 2) { m = args[1].d; if (m != 0 || m != 2 || m != 4 || m != 6) m = 0; } #ifdef Q_OS_WIN std::wstring path = ws(args[0].s.c_str()); int retValue = _waccess(path.c_str(), m); // 0 = OK, else -1 #else int retValue = 0; //waccess is a windows function, what is the Mac or QT equivalent ? #endif

hgy29

I am confused about what you call x64. Both QT and win32 exports are actually 64 bit, difference is that QT exports (so called desktop) relies on QT API, not specifically windows, whereas win32 export only relies on raw windows API.

MoKaLux

thank you captain hgy29, sorry about mixing things up
So desktop exports could be free from Qt if we only use raw windows API?
Like the c++ example I have given using only windows API and using #ifdef Q_OS_WIN...
This is good news

hgy29

Well, QT/desktop export is supposed to be for Mac and Linux too. To sum up, in Gideros desktop export choices you have:
- Windows Desktop: export for windows based on QT cross platform API, 64 bit but requiring a QT license
- Mac OS X desktop: export for mac based on QT cross platform API but requiring a QT license
- Apple: export targetting iOS/ipadOS/tvOS and mac OS. Using native apple tooling. Requires Xcode.
- UWP: export for windows (Universal Windows Platform). No license required but a microsoft developper account is needed to push to the Windows Store. Requires Visual Studio 2022. Produces app packages suitable for the Windows Store.
- Win32: export for windows (legacy Win32 API). 64 bit export, despite its name, not requiring any tool nor license. Produce traditionnal .exe files.

Gideros used to be for mobile platforms, and didn't have a desktop export for a long time. It had a player running on desktop though, so first desktop export introduced (by @john26 IIRC) was in fact a modified player app, based on QT like the other gideros tools.

It was the easiest path, but QT is heavy (and has licensing issues), so @john26 also added a raw win32 export and there was a kickstarter for adding a more modern WinRT/UWP export. I added the native macOS export recently based on iPhone export given the similar API they use in their OSes.

As of today, Desktop/QT export isn't the best choice for Windows, and probably not for Mac either, but it is still the more maintained of all since it is basically Gideros Player code.
I invested a lot of time in maintaining UWP export, but MS seems to deprecate UWP API. Win32 has been deperacted for years, but it is still so widely used that they can't drop it. MS is incitating developpers to move to "Windows App SDK", which seems to be a mix of Win32 and UWP features. I frankly don't know where we are going...

MoKaLux

thank you for the detailed explanations, I was confused about win32 not being 64 bit
I have been using win32 but for some reasons there are quite a few annoying differences between win32 export and Qt export
A few examples from previous posts: windows dialog file propagating the mouse events to the app, Qt code is executed when opening a file dialog but in win32 code is executed after the file dialog is closed, timing is also different, no r3d, values set correctly in Qt won't work in win32, ... I have my app as a proof

I was fighting against the differences but I gave up using win32

Hopefully Qt will change their license or lower their license price

As for windows UWP I don't really like the microsoft store, I prefer downloading from the web despite the security risks.

You are doing a lot of work hgy29 and you managed to bring GIDEROS to VERY HIGH STANDARDS, I cannot thank you enough for all you are doing captain . I still will be honored to help!

Viva Gideros

keszegh

at least as a dream, we should not give up though on having fully working exports without qt, as the qt licence stuff always comes up and is far from optimal.

hgy29

Gideros tries to hide the differences between platforms, but there are always a few differences that cannot be hidden. Can't really do much about timings, some platforms do some things asynchronously, while other do it synchronously, so generally speaking one shouldn't assume bhevaior to be the same on all platforms.

That said, R3D should work without any issues, and mouse event on native dialogs shouldn't be propagated to the app, those are to be considered as bugs at Gideros side. I appreaciate your reports about what doesn't work in win32 export, and I'll do my best fixing them. I have to admit it is hard to keep them on the radar, it'd be nice to have a place (maybe github) where they could stay until fixed.

I am on your side about QT, their abstraction layer is very nice but the licensing stuff ruins it all, given their abusive (again in my opinion) pricing.

hgy29

About 32bit/64bit, I double checked and you were right, win32 is still using mingw32, so technically 32bit, but it could as well be compiled with mingw64 in the future.

keszegh

hgy29 said:

About 32bit/64bit, I double checked and you were right, win32 is still using mingw32, so technically 32bit, but it could as well be compiled with mingw64 in the future.

perhaps it could be 64bit and also renamed to something reflecting this fact.

hgy29

About mouse events being propagated, I just tried and it is something else: mouse events are not propagated when mouse in the the file dialog window, but only when mouse goes back to gideros window (that's expected), BUT they are not dispatched in real time, all the events are sent when you close the file dialog. That's because the file dialog is blocking event processing, I'll try to fix that

hgy29

Found the issue with file dialog, we forgot to set the window handle in the Show call. Now mouse events are no longer recorded when the dialog is open. Tried R3D too: the physics plugin seem to work, but not the 3D lighting. I'll look a bit deeper.

hgy29

Ok, found a couple of issues, fixed here: https://github.com/gideros/gideros/commit/e25c3f73bbf0e101b2ff6a77a66998a3956dcec2

keszegh

btw i guess that the main api is supperted by win32, right? (up to some inconsistencies like the ones discussed above) or what api parts are not?
it would be great to have the relevant support icons next to the plugins on this page too:
https://wiki.gideros.rocks/index.php/Plugins
so one can quickly check if his needs are met using a win32 export or if qt is needed.
or some wiki page for differences would be nice (if there are main ones besides the plugins).
i'd like to move away from qt for a long time but i use some plugins that i think are not supported.

keszegh

i just tried to export my app to win32 to see what plugins don't work but instead i got stuck earlier, my app crashed by not finding a png image in a subfolder. i checked, the file name and the searched file are both all lowercase, so i don't know what else might be the issue.