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

doug moen doug at moens.org
Mon Sep 24 15:23:00 EDT 2018


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::
> applicationDirPath().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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180924/9c596e1e/attachment.html>


More information about the Discuss mailing list