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

Feature parity for win32 version

12357

Comments

  • MoKaLuxMoKaLux Member
    edited February 16
    returning to the previous post with apps name starting with a number, I managed to do it but it is hardcoded :p
    \gdrexport\ExportBuiltin.cpp
        else if(ctx->deviceFamily == e_Win32){
    //    	ctx->replaceList[0] << qMakePair(bytepad(ctx->templatenamews.toLatin1(),256), bytepad(ctx->basews.toLatin1(),256));
        	ctx->replaceList[0] << qMakePair(bytepad(ctx->templatenamews.toLatin1(),256), bytepad(QString("3DPixel").toLatin1(),256));
    //    	ctx->replaceList[0] << qMakePair(bytepad(QString("Win32 Template App Name").toUtf8(),256), bytepad(ctx->appName.toUtf8(),256));
        }
    result: C:\Users\xxx\AppData\Roaming\3DPixel :)

    PS: I tried toUft8 instead of toLatin1 but had same result as before _DPixel, I tried setting spacing to false but got DPixel :D , ... I challenged myself and had a good time looking into this small issue in c++, I think I like problem solving although I didn't solve it :p

    PS2: "Win32 Template App Name" seems to be for the app title but I had no issue commenting it out, the app title is still correctly set! (oh silly me I set it through code ;) )

    PS3: that doesn't work either because the hardcoded path is not passed to other functions so my app doesn't access it :o I have to redo it again :s
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    @keszegh, mine is an intuos 4 (ptk840). It worked out of the box with Qt, without Wacom drivers. For win32, it wasn’t recognized as a tablet at first, I had to install Wacom drivers for win10, then I started seeing the stylus as a pen, with pressure being reported. I didn’t try again in Qt with official Wacom driver. Will do later.
  • hgy29hgy29 Maintainer
    Good news: indeed QT didn't recognize hover event anymore when using Wacom drivers, because a flag was missing in our app to tell QT we are tablet aware. I fixed it, seems good now: https://github.com/gideros/gideros/commit/d19d93dcdba156a61668695f543de67d84e361f6
    Now why it doesn't work for you in win32 while it works for me ? I am on Win 11 using Wacom 6.3.41 driver package.

    Likes: keszegh, MoKaLux

    +1 -1 (+2 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    Also, I added spout plugin to win32, not tried yet, and I had to raise minimum supported Win version 8 for win32 export, in order to be able to support touch devices. It can be problematic if we want to keep Win 7 support.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29 said:

    Also, I added spout plugin to win32, not tried yet, and I had to raise minimum supported Win version 8 for win32 export, in order to be able to support touch devices. It can be problematic if we want to keep Win 7 support.

    cannot be this a flag upon export or is it too complicated?
  • keszeghkeszegh Member
    edited February 16
    hgy29 said:


    Now why it doesn't work for you in win32 while it works for me ? I am on Win 11 using Wacom 6.3.41 driver package.

    i use wacom driver 6.4.1-3
    so for you my app recognized pressure too? (don't forget to turn on pressure sensitivity in menu otherwise pen width is based on drawing speed, which also feels like 'pressure sensitive' but it is just fake.)
    also setting wintab driver on-off in my app (now visible only in qt version, does it make sense for win32?) needs restart.

  • keszeghkeszegh Member
    edited February 16
    or the other ways, perhaps you can also send me @hgy29 your test project you use to check win32 pressure sensitivity.
  • @hgy29 , i've tested it with a simple app and indeed win32 receives pressure. now i have to see where my app loses it (there are many workarounds added to avoid double-registering pen down events both as pen and mouse and so on, perhaps not even needed in win32 version).
    afternoon i will try to correct my code (if you find the issue in it, let me know).
  • @hgy29 , i've found the issue. on win32 event.type is "pen" whereas on qt it is "penTablet" and i was checking for the latter. perhaps it should be the same on both, right?
  • hgy29hgy29 Maintainer
    well on win32, I only have 'pen' type, no 'penTablet' distinction
  • i see, ok, that's fine.

    i will praise your work later.

    meanwhile a bug: on win32 if i exit the app by closing it with 'x' in corner then it does not trigger quit event it seems.
  • hgy29hgy29 Maintainer
    keszegh said:

    hgy29 said:

    Also, I added spout plugin to win32, not tried yet, and I had to raise minimum supported Win version 8 for win32 export, in order to be able to support touch devices. It can be problematic if we want to keep Win 7 support.

    cannot be this a flag upon export or is it too complicated?
    It would mean compiling several versions of the .exe (I think we can drop the console one btw), but if we go 64bit we'll drop some older configs anyway
  • hgy29hgy29 Maintainer
    keszegh said:


    meanwhile a bug: on win32 if i exit the app by closing it with 'x' in corner then it does not trigger quit event it seems.

    True, I added necessary code just now.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • about penTablet, does this mean that on qt there is also a 'pen' as a possible type? i thought penTablet is just a randomly chosen string (and thus it can be the same string on win32)
  • hgy29hgy29 Maintainer
    Yes, qt can report "pen" too, I think it is more a question of driver or where the event came from (which API), but IMO pen and penTablet can be considered as being the same, although I'd say pen would be for pens on touch capable PC, while penTablet would be more for wacom-like tablets.

    In QT, penTablet is reported for tabletEvents (whatever the real source is), here: https://github.com/gideros/gideros/blob/master/player/Sources/glcanvas.cpp#L1262
    Pen event is part is generic touch events, here: https://github.com/gideros/gideros/blob/master/player/Sources/glcanvas.cpp#L1333

    At win32 level, we use WM_POINTER* events, which only gives us PT_PEN and PT_TOUCH (finger) specific types: https://github.com/gideros/gideros/blob/master/win32_example/win32.cpp#L679
  • hgy29hgy29 Maintainer
    MoKaLux said:

    I have a problem with gideros documents path (docsPath).

    I think setting 'underscore = false' in ExportBuiltin.cpp/win32 section above, is enough to fix your issue.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • thanks for the explanation, so i will look for both pen and penTablet type when trying to use pressure, as both give pressure.
  • keszeghkeszegh Member
    edited February 16
    so overall my win32 app seems to perform as good as on qt by briefly testing. should there be some risky thing i should check for before publishing my apps win32 version instead of qt? (it is even half the size and i guess it should perform better than qt or at least not worse, right?)

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • keszeghkeszegh Member
    edited February 16
    hgy29 said:

    keszegh said:

    hgy29 said:

    Also, I added spout plugin to win32, not tried yet, and I had to raise minimum supported Win version 8 for win32 export, in order to be able to support touch devices. It can be problematic if we want to keep Win 7 support.

    cannot be this a flag upon export or is it too complicated?
    It would mean compiling several versions of the .exe (I think we can drop the console one btw), but if we go 64bit we'll drop some older configs anyway
    drop anything needed then, win 7 rings nice memories for me, i even have an old laptop still using that, so a bit harder to let it go, but probably only a minority of people use it by now anyway.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • i've updated the initial post. amazing work done on win32 in the last few days @hgy29 , i can probably switch to it soon completely. also thanks @MoKaLux on keeping win32 version on the horizon, otherwise i think this would not have happened.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • keszeghkeszegh Member
    edited February 16
    btw the console exe is very useful for testing purposes, but perhaps it should be optional (with a tickbox upon export).

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • there is a bug with screen:setTitle on win32, it actually sets the title of the main window and not of the new screen.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • bug: reactphysics plugin dll is packaged with the win32 version even though i don't use it.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    yes for reactphysics plugin, I know that, a few other plugins are present in the template. It was easier for debugging, but they should be removed in the final package. I will remove them.

    Likes: MoKaLux, keszegh

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

    there is a bug with screen:setTitle on win32, it actually sets the title of the main window and not of the new screen.

    Good catch, I probably copied/pasted the code for main window and forgot the change the handle. Fixed.

    Likes: keszegh, MoKaLux

    +1 -1 (+2 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited February 17
    Some feedback:
    hgy29 said:

    I think setting 'underscore = false' in ExportBuiltin.cpp/win32 section above, is enough to fix your issue.

    MoKaLux said:

    PS: I tried toUft8 instead of toLatin1 but had same result as before _DPixel, I tried setting spacing to false but got DPixel

    Sorry you should have read: "I tried setting spacing underscore to false but got DPixel".
    So either underscore true or false will drop the number :/
    More details:
    - underscore true: drops only the first number 3DPixel > _DPixel
    - underscore true: drops only the first number D3Pixel > D3Pixel
    - underscore false: drops all numbers? 3DPixel > DPixel
    - underscore false: drops all numbers? D3Pixel > DPixel
    keszegh said:

    btw the console exe is very useful for testing purposes...

    I use console in my app to give feedback to the users, can we please keep it :) . I find it better than alert box and stuff.

    I updated my repo with latest gideros gh but when I compile and run my app I have this message:

    In the Build.Tools folder I have libgcc_s_seh-1.dll. With all the changes, I may need to clone gideros to a brand new folder though.

    Thank you guys o:)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    edited February 17
    @MoKaLux, you need to switch to x86_64 tool chain in Mingw: in your Makefile,def change the win32_bin variable to mingw64 folder instead of mingw32, and install 64 bit tool chain: https://wiki.gideros.rocks/index.php/Compiling_Gideros_Source#1.2_.28PC.29_Install_MSYS2_Console

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited February 17
    Switched to x86_64 tool chain (via msys cmd) and my makefile.def is:
    #WIN32_BIN=/mingw32/bin
    #WIN32_BIN=/c/msys64/mingw32/bin
    WIN32_BIN=/c/msys64/mingw64/bin
    export WIN32_BIN
    I am trying but get these errors in msys:
    C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe
    : win32_example/build/libgvfs/gpath.o:gpath.cpp:(.text.unlikely+0x5): undefined reference to `__ZNSt
    7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv'
    C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe
    : win32_example/build/libgvfs/gpath.o:gpath.cpp:(.text.unlikely+0xd): undefined reference to `__Unwi
    nd_Resume'
    C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe
    : win32_example/build/libgvfs/gpath.o:gpath.cpp:(.text.startup+0x3d): undefined reference to `_atexi
    t'
    collect2.exe: error: ld returned 1 exit status
    make[1]: *** [/c/dev/gideros_dev/scripts//GidWin32.mk:63: win32.libs.build] Error 1
    make[1]: Leaving directory '/c/dev/gideros_dev'
    make: *** [/c/dev/gideros_dev/scripts//GidWin32.mk:58: gvfs.win32.libs] Error 2
     
    xxx@DESKTOP-xxx MSYS /c/dev/gideros_dev
    $
    Error at line scripts//GidWin32.mk:63:
    	at$(WIN32_CXX) -municode -g -o $(WIN32_BUILDDIR)/$(LIBNAME).dll -shared $^ $(LIBS)
    Looking into this :)
    Nevermind if it is working for you, I will wait for the next Gideros :)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    Did you issue a clean command ? make -f script/Makefile.gid win32.clean

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
Sign In or Register to comment.