V
vulcan_@mac.com
Sat, Sep 20, 2025 1:03 AM
I cannot reproduce the bug with “Save A Copy ..” that is reported in issue #6183 but i would like a small change in its operation …
I have always liked to have “_copy“ appended to an existing file name in the File Dialog when doing Save A Copy, so i have added code in TabManager.cc to do just that ..
I think.
Compiling in Windows is a challenge I have not yet mastered so I cannot test the code and i am not sure i am using the features of Qt correctly so .. feedback requested on
https://github.com/bitbasher/openscad-bit/blob/bitbasher-bug-fixes/src/gui/TabManager.cc
lines starting at 668, please.
I cannot reproduce the bug with “Save A Copy ..” that is reported in [issue #6183](https://github.com/openscad/openscad/issues/6183) but i would like a small change in its operation …
I have always liked to have “_copy“ appended to an existing file name in the File Dialog when doing Save A Copy, so i have added code in TabManager.cc to do just that ..
I think.
Compiling in Windows is a challenge I have not yet mastered so I cannot test the code and i am not sure i am using the features of Qt correctly so .. feedback requested on
https://github.com/bitbasher/openscad-bit/blob/bitbasher-bug-fixes/src/gui/TabManager.cc
lines starting at 668, please.
V
vulcan_@mac.com
Sat, Sep 20, 2025 1:06 AM
and .. would making a PR be a normal way to ask for feedback? I had started to write one up but thought better of it and came here
and .. would making a PR be a normal way to ask for feedback? I had started to write one up but thought better of it and came here
MK
Marius Kintel
Sat, Sep 20, 2025 1:17 AM
Yes, PR is a lot better.
But for GUI changes specifically, the crucial part is that is should be tested and verified manually, as nobody else is likely to build and run and test the code on your behalf.
Doing this under Windows can be tricky. If you have access to a macOS or Linux machine, this should be a bit more streamlined for now.
-Marius
On Sep 19, 2025, at 21:06, vulcan_--- via Discuss discuss@lists.openscad.org wrote:
and .. would making a PR be a normal way to ask for feedback? I had started to write one up but thought better of it and came here
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Yes, PR is a lot better.
But for GUI changes specifically, the crucial part is that is should be tested and verified manually, as nobody else is likely to build and run and test the code on your behalf.
Doing this under Windows can be tricky. If you have access to a macOS or Linux machine, this should be a bit more streamlined for now.
-Marius
> On Sep 19, 2025, at 21:06, vulcan_--- via Discuss <discuss@lists.openscad.org> wrote:
>
> and .. would making a PR be a normal way to ask for feedback? I had started to write one up but thought better of it and came here
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
FH
Father Horton
Sat, Sep 20, 2025 1:38 AM
Use WSL. I have built OpenSCAD that way.
On Fri, Sep 19, 2025 at 8:17 PM Marius Kintel via Discuss <
discuss@lists.openscad.org> wrote:
Yes, PR is a lot better.
But for GUI changes specifically, the crucial part is that is should be
tested and verified manually, as nobody else is likely to build and run and
test the code on your behalf.
Doing this under Windows can be tricky. If you have access to a macOS or
Linux machine, this should be a bit more streamlined for now.
-Marius
On Sep 19, 2025, at 21:06, vulcan_--- via Discuss <
discuss@lists.openscad.org> wrote:
and .. would making a PR be a normal way to ask for feedback? I had
started to write one up but thought better of it and came here
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Use WSL. I have built OpenSCAD that way.
On Fri, Sep 19, 2025 at 8:17 PM Marius Kintel via Discuss <
discuss@lists.openscad.org> wrote:
> Yes, PR is a lot better.
> But for GUI changes specifically, the crucial part is that is should be
> tested and verified manually, as nobody else is likely to build and run and
> test the code on your behalf.
>
> Doing this under Windows can be tricky. If you have access to a macOS or
> Linux machine, this should be a bit more streamlined for now.
>
> -Marius
>
> On Sep 19, 2025, at 21:06, vulcan_--- via Discuss <
> discuss@lists.openscad.org> wrote:
>
> and .. would making a PR be a normal way to ask for feedback? I had
> started to write one up but thought better of it and came here
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Sat, Sep 20, 2025 2:37 AM
I think the MSYS2 build process is now fairly straightforward. I don't
remember having significant trouble the last time I started from
scratch; I think I just ran the commands the instructions told me to run.
It doesn't build a "real" Windows executable - it depends on a number of
MSYS2 libraries - but it's a good start.
And if you're patient, if you file a PR the CI build will make you an
installer. It just takes half an hour or so, versus maybe 3-4m on my
not-that-spectacular desktop.
I think the MSYS2 build process is now fairly straightforward. I don't
remember having significant trouble the last time I started from
scratch; I think I just ran the commands the instructions told me to run.
It doesn't build a "real" Windows executable - it depends on a number of
MSYS2 libraries - but it's a good start.
And if you're patient, if you file a PR the CI build will make you an
installer. It just takes half an hour or so, versus maybe 3-4m on my
not-that-spectacular desktop.
GB
Glenn Butcher
Sat, Sep 20, 2025 3:03 AM
MSYS2 executables are real windows .exe files. That they depend on .dll library files not in the c:\windows\system32 directory is no different than an executable built with Microsoft tools.
On September 19, 2025 4:37:44 PM HST, Jordan Brown via Discuss discuss@lists.openscad.org wrote:
I think the MSYS2 build process is now fairly straightforward. I don't
remember having significant trouble the last time I started from
scratch; I think I just ran the commands the instructions told me to run.
It doesn't build a "real" Windows executable - it depends on a number of
MSYS2 libraries - but it's a good start.
And if you're patient, if you file a PR the CI build will make you an
installer. It just takes half an hour or so, versus maybe 3-4m on my
not-that-spectacular desktop.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
MSYS2 executables are real windows .exe files. That they depend on .dll library files not in the c:\windows\system32 directory is no different than an executable built with Microsoft tools.
On September 19, 2025 4:37:44 PM HST, Jordan Brown via Discuss <discuss@lists.openscad.org> wrote:
>I think the MSYS2 build process is now fairly straightforward. I don't
>remember having significant trouble the last time I started from
>scratch; I think I just ran the commands the instructions told me to run.
>
>It doesn't build a "real" Windows executable - it depends on a number of
>MSYS2 libraries - but it's a good start.
>
>And if you're patient, if you file a PR the CI build will make you an
>installer. It just takes half an hour or so, versus maybe 3-4m on my
>not-that-spectacular desktop.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
JB
Jordan Brown
Sat, Sep 20, 2025 3:20 AM
On 9/19/2025 8:03 PM, Glenn Butcher via Discuss wrote:
MSYS2 executables are real windows .exe files. That they depend on
.dll library files not in the c:\windows\system32 directory is no
different than an executable built with Microsoft tools.
Sure. I don't know how deep the dependency tree is or how many
libraries you'd have to copy, but if you copy enough it'll work.
My point, on which I was perhaps unclear, is that the executable that
results is not the same as the one that comes out of the production
build. A production openscad.exe does not appear to have any DLL
dependencies other than those in \Windows\System32; it appears that you
can copy only that openscad.exe to a different place, and it will
still work.
Perhaps there is a way to get the MSYS2 build to statically link the
libraries it uses. I don't know. The default MSYS2 build does dynamic
linking.
On 9/19/2025 8:03 PM, Glenn Butcher via Discuss wrote:
> MSYS2 executables are real windows .exe files. That they depend on
> .dll library files not in the c:\windows\system32 directory is no
> different than an executable built with Microsoft tools.
Sure. I don't know how deep the dependency tree is or how many
libraries you'd have to copy, but if you copy enough it'll work.
My point, on which I was perhaps unclear, is that the executable that
results is not the same as the one that comes out of the production
build. A production openscad.exe does not appear to have any DLL
dependencies other than those in \Windows\System32; it appears that you
can copy *only* that openscad.exe to a different place, and it will
still work.
Perhaps there is a way to get the MSYS2 build to statically link the
libraries it uses. I don't know. The default MSYS2 build does dynamic
linking.
GB
Glenn Butcher
Sat, Sep 20, 2025 5:53 AM
True, MSYS2 library packages tend to be .dll files. When I want to make a Windows installer of a software, I'll use the Linux-based mxe cross-compiler. It builds an environment of all static- compiled libraries. I'd surmise openscad releases are made the same way.
On September 19, 2025 5:20:17 PM HST, Jordan Brown openscad@jordan.maileater.net wrote:
On 9/19/2025 8:03 PM, Glenn Butcher via Discuss wrote:
MSYS2 executables are real windows .exe files. That they depend on
.dll library files not in the c:\windows\system32 directory is no
different than an executable built with Microsoft tools.
Sure. I don't know how deep the dependency tree is or how many
libraries you'd have to copy, but if you copy enough it'll work.
My point, on which I was perhaps unclear, is that the executable that
results is not the same as the one that comes out of the production
build. A production openscad.exe does not appear to have any DLL
dependencies other than those in \Windows\System32; it appears that you
can copy only that openscad.exe to a different place, and it will
still work.
Perhaps there is a way to get the MSYS2 build to statically link the
libraries it uses. I don't know. The default MSYS2 build does dynamic
linking.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
True, MSYS2 library packages tend to be .dll files. When I want to make a Windows installer of a software, I'll use the Linux-based mxe cross-compiler. It builds an environment of all static- compiled libraries. I'd surmise openscad releases are made the same way.
On September 19, 2025 5:20:17 PM HST, Jordan Brown <openscad@jordan.maileater.net> wrote:
>On 9/19/2025 8:03 PM, Glenn Butcher via Discuss wrote:
>> MSYS2 executables are real windows .exe files. That they depend on
>> .dll library files not in the c:\windows\system32 directory is no
>> different than an executable built with Microsoft tools.
>
>Sure. I don't know how deep the dependency tree is or how many
>libraries you'd have to copy, but if you copy enough it'll work.
>
>My point, on which I was perhaps unclear, is that the executable that
>results is not the same as the one that comes out of the production
>build. A production openscad.exe does not appear to have any DLL
>dependencies other than those in \Windows\System32; it appears that you
>can copy *only* that openscad.exe to a different place, and it will
>still work.
>
>Perhaps there is a way to get the MSYS2 build to statically link the
>libraries it uses. I don't know. The default MSYS2 build does dynamic
>linking.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
V
vulcan_@mac.com
Sat, Sep 20, 2025 8:08 AM
And if you're patient, if you file a PR the CI build will make you an
installer. It just takes half an hour or so, versus maybe 3-4m on my
not-that-spectacular desktop.
i like that .. being the lazy soul that i am .. where do i find the installer file to download ?
i am about to start hunting for it .. but GitHub is really good at hiding stuff when
you are looking for things ..
Jordan Brown wrote:
> And if you're patient, if you file a PR the CI build will make you an
> installer. It just takes half an hour or so, versus maybe 3-4m on my
> not-that-spectacular desktop.
i like that .. being the lazy soul that i am .. where do i find the installer file to download ?
i am about to start hunting for it .. but GitHub is _really_ good at hiding stuff when\
you are looking for things ..
JB
Jordan Brown
Sat, Sep 20, 2025 5:30 PM
i like that .. being the lazy soul that i am .. where do i find the installer file to download ?
I don’t do it very often so I don’t know where it is exactly. I believe it’s under the CI build in the list of checks, and it’s under “artifacts”.
> i like that .. being the lazy soul that i am .. where do i find the installer file to download ?
I don’t do it very often so I don’t know where it is exactly. I believe it’s under the CI build in the list of checks, and it’s under “artifacts”.
