How about this:

Usage: openscad.exe [options] file.scad
Allowed options:
-o [ --o ] arg        out_file -output a file instead of running the GUI,
the
file extension specifies the type: stl, off, amf,
csg,
dxf, svg, png, echo, ast, term
-D [ --D ] arg        var=val -pre-define variables
-d [ --d ] arg        deps_file -generate a dependency file for make
-m [ --m ] arg        make_cmd -runs make_cmd file if file is missing
-h [ --help ]        print this help message and exit
-v [ --version ]      print the version
--info                print information about the build process
--csglimit arg        if exporting a png image, stop rendering at the
given
number of CSG elements
--camera arg          camera parameters when exporting png:
translate_x,y,z,rot_x,y,z,dist or
eye_x,y,z,center_x,y,z
--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
evaluation
--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 | Sunset | Metallic |
Starnight |
BeforeDawn | Nature | DeepOcean
-p [ --p ] arg        customizer parameter file
-P [ --P ] arg        customizer parameter set
-s [ --s ] arg        stl-file deprecated, use -o
-x [ --x ] arg        dxf-file deprecated, use -o
--enable arg          enable experimental features
--debug arg          special debug info
-q [ --quiet ]        quiet mode (don't print anything except errors)

The list of colour schemes need to be generated programmatically as well
because it inevitable doesn't match those in the menu.

On 24 September 2018 at 02:52, TLC123 torleif.ceder@gmail.com wrote:

Re-ordered to put more obscure options later and color scheme list
generated programmatically.

Usage: openscad.exe [options] file.scad
Allowed options:
-o [ --o ] arg        out_file -output a file instead of running the GUI,
the
file extension specifies the type: stl, off, amf,
csg,
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
-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
eye_x,y,z,center_x,y,z
--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
evaluation
--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 |
Starnight
| BeforeDawn | Nature | DeepOcean | Solarized |
Tomorrow | Tomorrow Night | Monotone
--csglimit arg        if exporting a png image, stop rendering at the
given
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
--enable arg          enable experimental features
--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 13:17, nop head nop.head@gmail.com wrote:

On Mon, Sep 24, 2018 at 02:19:11PM +0100, nop head wrote:

Would it be possible to print a "*" next to the currently selected
colorscheme? That would normally be the default one, but it should be
the "currently selected" that is tagged to accomodate configurations
where say an environment variable changes the default.

Roger.

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Yes, easy, but I have found that a side effect of accessing the ColorMap
class early is to make the GUI lock up at the splash screen.

On 24 September 2018 at 14:24, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

On Mon, Sep 24, 2018 at 02:39:09PM +0100, nop head wrote:

So... Not easy then. :-)

Roger. 

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

The problem is moving this code from cmdline() to main() because ColorMap
needs application path to registered.

#ifdef OPENSCAD_QTGUI
QCoreApplication app(argc, argv);
const std::string application_path =
QCoreApplication::instance()->applicationDirPath().toLocal8Bit().constData();
#else
const std::string application_path =
fs::absolute(boost::filesystem::path(argv[0]).parent_path()).generic_string();
#endif

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.

On 24 September 2018 at 14:39, nop head nop.head@gmail.com wrote:

Actually there is no currently selected colourscheme when using the command
line. The default is hard coded to cornfield, regardless of what is
selected in the GUI.

On 24 September 2018 at 15:03, nop head nop.head@gmail.com wrote:

On 09/24/2018 04:03 PM, nop head wrote:

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.

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@gmx.de wrote: