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

nop head nop.head at gmail.com
Mon Sep 24 14:29:51 EDT 2018

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

More information about the Discuss mailing list