Feature parity for win32 version

MoKaLux

for win32 app icon we can use http://www.angusj.com/resourcehacker/ I used it in the past and may as well use it again, it is very easy

for ref:
https://github.com/gideros/gideros/blob/fa9216b821dbf1c88b81f65c5cd03c6edcb946c0/gdrexport/ExportBuiltin.cpp#L412

https://learn.microsoft.com/en-us/windows/win32/menurc/using-icons#displaying-an-icon

MoKaLux

returning to the previous post with apps name starting with a number, I managed to do it but it is hardcoded
\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 , ... 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

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 I have to redo it again

hgy29

@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.

hgy29

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.

hgy29

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.

keszegh

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?

keszegh

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.

keszegh

or the other ways, perhaps you can also send me @hgy29 your test project you use to check win32 pressure sensitivity.

keszegh

@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).

keszegh

@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?

hgy29

well on win32, I only have 'pen' type, no 'penTablet' distinction

keszegh

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.

hgy29

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

hgy29

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.

keszegh

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)

hgy29

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

hgy29

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.

keszegh

thanks for the explanation, so i will look for both pen and penTablet type when trying to use pressure, as both give pressure.

keszegh

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?)

keszegh

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.

keszegh

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.

keszegh

btw the console exe is very useful for testing purposes, but perhaps it should be optional (with a tickbox upon export).

keszegh

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

keszegh

bug: reactphysics plugin dll is packaged with the win32 version even though i don't use it.

hgy29

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.

hgy29

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.

MoKaLux

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

hgy29

@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

MoKaLux

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

hgy29

Did you issue a clean command ? make -f script/Makefile.gid win32.clean