SketchEl 2 is the successor to the original SketchEl application, which was written in Java, using the Swing toolkit, and provided an applet-based web plugin (which is now obsolete).
As of June 2017, the project is very early: there is no guarantee that it is fit for any purpose, but you are welcome to try it out, provide feedback and/or submit patches.
The whole project is copyrighted by Molecular Materials Informatics, Inc and made available via the GNU Public License (GPL) v3. In a nutshell, this is the patent-unfriendly viral license: you can use it for whatever you want, but derived software gets infected with the same license.
To compile a functioning build, you will need to have WebMolKit setup in a parallel directory, e.g.
The primary technology of interest that has to be installed is TypeScript, which is easy enough to setup: just follow the instrutions.
TypeScript is a cross-compiler, which essentially turns all of the files in the
src/**.ts subdirectory (and the WebMolKit
the GitHub fileset and updated with each source change, so you can continue with the build process without updating it.
tsc: it reads the
file to figure out what needs to be done. For viewing or editing the source files, the best option is Visual Studio Code
(the excellent cross platform open source project: not to be confused with Visual Studio).
The first step to building a package is to install the Electron library in the
SketchEl2 folder. This is not included in the git
repository, so you have to install it from the standard location. Assuming you already have
npm (Node.js Package Manage) installed, see
remake_prebuild.sh. Running this will create and populate the
Once this is configured, you can either try your luck with the system wide
electron_packager binary, or use one of the three shell
scripts provided (
winbuild.sh), which will populate the
directory with a functioning app, if all goes well.
The deliverables are quite different per platform, and your mileage may vary when trying to build for a platform that you're not currently running. At the present time, it has only been tested with Linux and macOS, although it is highly probable that the Windows analog will also work (feedback welcome on whether this is the case).
Note there is an annoying bug that afflicts TypeScript/Visual Studio Code: when there is a
node_modules directory, the UI and
compiler scan through all of the TypeScript interfaces within that directory, even though it is not supposed to (and even when it is explicitly told
not to), which generates a slew of compiler warnings. This will presumably be fixed sometime, but it is currently problematic, because the
Electron package manager only works when its files are stored locally (i.e. in the local
node_modules directory). It should work
with a global installation (i.e. when those files are stored somewhere else, like /usr/local/lib), but it does not. The workaround is rather ugly: the
build scripts make a symbolic softlink to the global installation, build the package, then remove the link. This works, and it is necessary when
alternating between debugging and building the package. If you are not going to recompile, or you just compile once and are willing to ignore the
warnings, then this workaround is nonessential.
Editing or viewing source code should be done with Visual Studio Code. The configured
file should provide everything you need to simply open up the project and hit run. For getting started quickly, this may be simpler than
building the package.