[OpenSCAD] Light source and default camera position different on command line

nop head nop.head at gmail.com
Mon Sep 24 15:45:10 EDT 2018


I think argv[0] is the full path of the executable on Windows, regardless
of what you type, but on Linux it is just what you typed. Does your code
cope with it being a full path like
C:/msys64/home/ChrisP/openscad/release/openscad.exe?

On 24 September 2018 at 20:23, doug moen <doug at moens.org> wrote:

> const std::string application_path = fs::absolute(boost::filesystem
> ::path(argv[0]).parent_path()).generic_string();
>
> This code won't work. Suppose that you git clone the OpenSCAD repository,
> build it, and install it in some place like /usr/local/bin. Then, when you
> type 'openscad' from a bash prompt, then argv[0] will just be the string
> "openscad", with no directory component. application_path should be set to
> "/usr/local/bin", but this code won't return the correct directory.
>
> I have a function called 'progdir()' which computes the application
> directory, portable between Linux and MacOS. However, I've never tested my
> code on Windows. You can have the code if you want it. progdir() works by
> searching the PATH environment variable, when necessary, to determine the
> application path.
>
> How important is it for OpenSCAD to work correctly if it is built without
> linking to Qt?
>
> On 24 September 2018 at 14:33, nop head <nop.head at gmail.com> wrote:
>
>> #ifdef OPENSCAD_QTGUI
>>     const std::string application_path = QCoreApplication::applicationD
>> irPath().toLocal8Bit().constData();
>> #else
>>     const std::string application_path = fs::absolute(boost::filesystem
>> ::path(argv[0]).parent_path()).generic_string();
>> #endif
>>      PlatformUtils::registerApplicationPath(application_path);
>>
>> Much nicer!
>>
>> On 24 September 2018 at 19:29, nop head <nop.head at gmail.com> wrote:
>>
>>> Actually QCoreApplication::applicationDirPath() is static so I don't
>>> need an instance.
>>>
>>> On 24 September 2018 at 19:27, nop head <nop.head at gmail.com> wrote:
>>>
>>>> The way it currently works is if it runs the GUI then it gets the
>>>> application path from the OpenSCADApp instance. If it runs the command line
>>>> version it instantiates a QCoreApplication app and uses that. Only if it is
>>>> compiled without QT does it use the boost version.
>>>>
>>>> To get the color schemes in the command line description it needs the
>>>> app path before it has processed the command line. I bodged it by always
>>>> creating a QCoreApplicationapp on the heap, using it to get the app path
>>>> and then deleting it. That seems to fix the problem and still uses QT if
>>>> compiled with QT.
>>>>
>>>> #ifdef OPENSCAD_QTGUI
>>>>     QCoreApplication *app = new QCoreApplication(argc, argv);
>>>>     const std::string application_path = QCoreApplication::instance()->
>>>> applicationDirPath().toLocal8Bit().constData();
>>>>     delete app;
>>>> #else
>>>>     const std::string application_path = fs::absolute(boost::filesystem
>>>> ::path(argv[0]).parent_path()).generic_string();
>>>> #endif
>>>>     PlatformUtils::registerApplicationPath(application_path);
>>>>
>>>> Can anybody see a problem with this hack?
>>>>
>>>>
>>>> On 24 September 2018 at 18:28, Torsten Paul <Torsten.Paul at gmx.de>
>>>> wrote:
>>>>
>>>>> On 09/24/2018 04:03 PM, nop head wrote:
>>>>>
>>>>>> Having two QT app instances seems to be a problem, no surprise there!
>>>>>> Is there a reason for preferring the QT version? The boost version
>>>>>> produces the same path on my system so using that solves the problem.
>>>>>>
>>>>>> The current code might be just for legacy reasons, but there are
>>>>> various
>>>>> issues with boost on Windows regarding hard-links and non-ascii path.
>>>>> I don't know if the toLocal8Bit() from Qt is better, but it might
>>>>> actually
>>>>> help in those cases. Otherwise it would be nicer to just have a single
>>>>> way to determine the path.
>>>>>
>>>>> The command line help change looks very nice. I think that using the
>>>>> generated version is much better as this pretty much removes the risk
>>>>> of information missing in the output in case of future changes to the
>>>>> options.
>>>>>
>>>>> ciao,
>>>>>   Torsten.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> Discuss at lists.openscad.org
>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss at lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180924/e1edc274/attachment.html>


More information about the Discuss mailing list