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

nop head nop.head at gmail.com
Mon Sep 24 14:33:44 EDT 2018


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


More information about the Discuss mailing list