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

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

A bit more re-ordering, some blank line separators and a list of
experimental features available. Anybody got any suggestions before I make
a PR.

Usage: openscad.exe [options] file.scad
Allowed options:
  -o [ --o ] arg        out_file -output a file instead of running the GUI,
                        file extension specifies the type: stl, off, amf,
                        dxf, svg, png, echo, ast, term, nef3, nefdbg
  -D [ --D ] arg        var=val -pre-define variables
  -p [ --p ] arg        customizer parameter file
  -P [ --P ] arg        customizer parameter set
  --enable arg          enable experimental features: assert | echo |
lc-each |
                        lc-else | lc-for-c | amf-import | svg-import |
  -h [ --help ]         print this help message and exit
  -v [ --version ]      print the version

  --camera arg          camera parameters when exporting png:
                        translate_x,y,z,rot_x,y,z,dist or
  --autocenter          adjust camera to look at object center
  --viewall             adjust camera to fit object
  --imgsize arg         =width,height for exporting png
  --render arg          if exporting a png image, do a full geometry
  --preview arg         if exporting a png image, do an OpenCSG(default) or
                        ThrownTogether preview
  --projection arg      (o)rtho or (p)erspective when exporting png
  --colorscheme arg     colorscheme: *Cornfield | Metallic | Sunset |
                        | BeforeDawn | Nature | DeepOcean | Solarized |
                        Tomorrow | Tomorrow Night | Monotone
  --csglimit arg        if exporting a png image, stop rendering at the
                        number of CSG elements

  -d [ --d ] arg        deps_file -generate a dependency file for make
  -m [ --m ] arg        make_cmd -runs make_cmd file if file is missing
  --info                print information about the build process
  --debug arg           special debug info
  -q [ --quiet ]        quiet mode (don't print anything *except* errors)
  -s [ --s ] arg        stl-file deprecated, use -o
  -x [ --x ] arg        dxf-file deprecated, use -o

On 24 September 2018 at 19:33, nop head <nop.head at gmail.com> wrote:

>     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.
>>>     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/91fdf3f3/attachment.html>

More information about the Discuss mailing list