Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Feature parity for win32 version - Page 2 — Gideros Forum

Feature parity for win32 version

24567

Comments

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

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited October 2022
    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++ o:)

    EDIT: I can now filter file extensions but it is hard coded, how do I get them from Gideros?
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLuxMoKaLux Member
    edited October 2022
    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 :s
    The good news is that application:get(saveFileDialog(title|path|extensions//help)) should now be easy to implement!? :p

    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 :)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    edited October 2022
    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.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited October 2022
    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 :p

    I am sorry but I have 2 more issues :o :
    - 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 :)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • rrraptor said:
    In this case I prefer not to touch it since it is Luau source file :s
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • good job guys, thanks for the progress

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    MoKaLux said:


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

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

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited November 2022
    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 :p and that worked on export for windows 64 and Gideros player :o 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++ :)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    I couldn't reproduce the crash,
    os.execute("start ".."c:\\tmp")
    works for me.
  • MoKaLuxMoKaLux Member
    edited November 2022
    (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 :s
    MoKaLux said:

    I am sorry but I have 2 more issues :o :
    - 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 :-(
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    lfs.chdir works here too
  • hgy29hgy29 Maintainer
    could it be because your user directory contains non Latin1 characters ? Mine is purely ASCII
  • MoKaLuxMoKaLux Member
    edited November 2022
    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 :s
    I am glad it is working for you.
    Could I have more people to try on their machines please?
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLuxMoKaLux Member
    edited November 2023
    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 :s

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

    Viva Gideros <3
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLuxMoKaLux Member
    edited February 2023
    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
    :o
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    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.
  • 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 :)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    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...

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited February 2023
    thank you for the detailed explanations, I was confused about win32 not being 64 bit :s
    I have been using win32 but for some reasons there are quite a few annoying differences between win32 export and Qt export :s
    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 :p

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

    Hopefully Qt will change their license or lower their license price :o

    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 <3
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • 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.
  • hgy29hgy29 Maintainer
    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.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    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.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • 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.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    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

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    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.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • 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.
  • 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.
Sign In or Register to comment.