Slic3r C++ GUI - Field/OptionGroup (Notes)

[lordofhyphens]

I've been mulling over how to make things cleaner and easier to work with on a Slic3r C++ UI and keeping the same general flow of the rest of the GUI packages and similar calling conventions.

As I work on it, I'll be committing the sample harness and files to a separate repository. Once I'm largely happy with it in both presentation and code usability (both through an XS shim and otherwise), it'll get merged into Slic3r proper. This message is here to note progress and to collect comments from other people like @alexrj. If we can use this to simplify the internals and/or calling conventions then I'd be great with that.

It's really rough (just the raw objects), part of my plans is to wrap it with some utility functions

I am also keeping i18n support in mind as I work on it (#1378 #789), hence the use of wxStrings (cleanly deal with unicode). All labels should be wrapped with _() (which is wxWidgets code for "this text gets translated"). I think that with a .po file and that usage the option labels, etc can be translated through an appropriate .po file.

https://github.com/lordofhyphens/gui-mockup

I'm not that happy atm about the way the return values are being passed out, as it requires the handling code deal with boost::any return values.

It does require a compiler that supports C++11. The provided makefile assumed gcc.

[CReimer]

Wouldn't it be better to get rid of wxWidgets and replace it with something more modern, like QT5?

[lordofhyphens]

We like wxwidgets. It works, is still active, and runs everywhere. The reason for moving to a C++ implementation is that the wxPerl bindings aren't being maintained anymore.

Sticking with wxWidgets rest of the code changes simplifies the rest of the work as well. This piece is the trickiest as it is on the fly UI building.

I don't see any value added to completely changing the underlying toolkit. Obviously if you want to spend the effort rewriting the UI to use qt5 then go nuts. I don't.

[bubnikv]

Technically the Qt library is a better idea. It is maintained, much richer, it behaves mostly equally on different platforms due to its own widget rendering engine.

wxWidgets on the other side is based on the Microsoft Foundation Classes. https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library

Actually the initial wxWidgets were very much a port of MFC over Motif X widgets: https://en.wikipedia.org/wiki/Motif_(software)

wxWidgets are maintained by a tiny group of volunteers, there is not really much of an active development. The library wraps around native widgets, which causes a lot of problems, often leading to implementing different code paths for different platforms.

Everyone I met working with wxWidgets swears a lot. The Qt folks are smiling.

[CReimer]

I've never done any GUI development before. But the Qt5 tutorial and the Qt Designer both look quite simple.

If you don't want to switch to Qt right away I'd take a look at it after the transition to C++ is done. I wouldn't want to mess around with Perl in combination with Qt.

[rob-miller]

I'm interested in contributing to Slic3r development, and was happy to discover that much of it is written in Perl so I could go directly into my (OS X) installation and fix things This means no hurdle at all to getting started helping, no issues for an initial build environment, and not too much worry about my contributions working on other platforms.

I came to this thread investigating whether contributing to Slic3r perl code is useful, or more of a dead end as it will all have to be converted to C++ anyway. I can contribute either way, but would be less likely to start if I had read here that changing the GUI to be perl-free is imminent.

One point above is that the WxPerl bindings aren't being maintained any more - but it appears that about a month after that post (April 17, 2017) a new version of WxPerl was released.

I find infrequent library updates to be a feature, not a bug. I regularly rebuild a program called PgModeller from source, and its Qt5 dependency is a moving target - currently not the latest version, nor a version supported by Homebrew on the Mac. 'The Qt folks' may smile about this, but for me the end user who just wants to build a package and move on it is a consistent and time consuming headache.

[lordofhyphens]

Found some time to work again on https://github.com/lordofhyphens/gui-mockup. This is a screenshot from my test harness (a minimal Wx application so I can get that side of things behaving and the config system acting together with libslic3r before I have to worry about any Perl bindings).

• Interfaces have been reworked more to depend on libslic3r.

  • You can create new OptionsGroup(s) and build fields that show up in PrintConfig.
  • Only TextCtrl is stubbed out at all.

• Stole the cmake configuration from trunk's src dir and tweaked it slightly to build my mockup and test system as a separate library. When it gets further along I'll integrate it into xs/slic3r/GUI.

• I think I have the interface correct so that callbacks can be bound to the event table. @alexrj could you provide a few hints about the expected context?

  • Is Field::on_change expected to call something in its owning class (that is, if an OptionGroup builds a Field, the Field is given a hook to a method that can reference the owning OptionGroup)?

[Patlax]

@lordofhyphens May you please provide libslic3r as a standalone-library, if possible?

as slic3r is a really powerfull tool, i would like to expand libslic3r by adding it to my project, in which 3D-Objects or .m3f-files are converted into .svg-files including their absolute contour points, as well as printing paths and information about their infills. Including infills is currently working with slicer only for DLP-printers using relative paths. This svg´s won´t work with 3d-printers or laser lithography systems. I couldn´t find a workaround by editing the export_svg-function in Print.pm since the Layer-class (acc. to my understanding) stores information aolely about the outer contour of the object.

When including libslic3r as a library into my project (tried it with (1) c++11/boost1.63.0 as well as (2) c++17/boost.1.84.0), many errors ((1) > 300, (2) > 150) occur.

Is there a even a way to include libslic3r into another project (e.g. qt/c++)? Did you try it and if so, with which config/settings?