Complete UI rework. New Java UI or Webbased?

[t-oster]

Well when I started VisiCut, NetBeans used the Swing Application Framework for UI by default. NetBeans has a nice UI Editor which makes it easy to create re-usable UI components and bind them to the underlying data model. However the UI Editor dropped support for this framework soon after NetBeans 7.0.1, so you cannot edit VisiCut's forms with recent versions of NetBeans.

It would be nice to re-create all of the UI with the new UI Editor of NetBeans and remove the dependency to the Swing Application Framework.

The question is, if we re-create the UI anyway, what is the way to go?

• Try to replace old forms by new forms as close as possible
• Switch from the Java-UI to a Webbased UI (re-using most code in an underlying JSF application)
• Completely re-write VisiCut in another language?

[peteruithoven]

I've always been a webbased guy, I see many benefits:

• More accessible, because it requires no installation.
• Easier to maintain, individual users don't have to update the app or the settings.
• There are more web developers in the world than Java developers, so I'm hoping we would get more contributors. 1 2
• Many, many resources, lot's of great frameworks (AngularJS, Ember.js, React, Bootstrap, Foundation, ...) and workflow improvements (npm, less, gulp, template languages etc)
• It should be much easier to share settings.
• Even more cross platform; tablets, smartphones etc. No more java installers.

But, this also means:

• Much more work
• Requires learning lot's of other technologies.
• Takes more work to setup for lasercutter owners / lab managers, they need to run the app or a small forwarding app on something like a raspberry pi connected to the lasercutter. See Octoprint or Chilipeppr's serial port JSON websocket server.

Other webbased examples that convinced me it's a good idea:

• http://jscut.org/
• http://chilipeppr.com/
• http://octoprint.org/
• http://openjscad.org/
• http://tinkercad.com/
• https://upverter.com/
• http://doodle3d.com/ (biased)

I'm very curious how you guys think about this.

[t-oster]

Well. If we decide not to just replace the old forms by new forms, I also vote for a webbased solution. But there are a whole jungle of Technologies out there, so it is not easy to choose.

There are three Basic ways to go for a webbased VisiCut:

1. Use the existing VisiCut as a Library in a Java EE Environment, meaning we create the Server component of VisiCut in Java. This would allow for most re-use of code, because all of the Input file reading, PLF processing etc is arelady there. What Needs to be done is a more or less simple Interface, etither in JavaServerFaces or plain HTML+ some fancy JS and CSS libraries, which does the following:

• provide a main page similar to VisiCut's current Frame.
• If the user Drops a file, just send it to the Server, where it will be loaded by VisiCut
• The Server will send the rendered Version of that file (depending on current mapping, zoom Level etc.) as a PNG with transparent Background, which can be moved around etc in the web Interface.
• all changes like resizing, changing the mapping etc result in a new Version of that png transmitted from the Server.

This Approach is the one with the least effort, plus it allows still for using visicut as it is. But the backend will still be Java.

1. Completely create a new Version, re-implementing all file and mapping stuff and just re-use lib-lasercut for the Hardware specific stuff. The application will then create the laser-Job object and pass it down to lib-laser-cut
2. Do a full re-write of all code.

[mgmax]

with the current java GUI there seem to be some performance issues, just try opening a large file and it will sometimes take ages to calculate some kind of engraving preview. If a webserver that often has more than one client also used that much processing time, we would get into trouble. Do we need to solve these issues first or are they only GUI-specific?

[t-oster]

The time for calculating a raster-preview is so slow, because VisiCut really tries to render it on (laser-)pixel accuracy. Just calculate how many pixels a small image on a 500 DPI Lasercutter has. For the preview, we could of cause use a much smaller version of the image, but this would generate aliasing effects and other distortions on the dithering algorithms. On the other hand, rendering this high-dpi image on a screen also causes aliasing effects, so the question is, do we need this high-resolution preview, or are there other preview-algorithms, which may even be closer to the real result?

[madeinoz67]

Have just started getting my hands dirty yesterday with Visicut developing a new driver for my current hardware, emblaser from darkly lab, so will add my 2c.

I Like Visicut as desktop client, easy to install and run. If you go down a WebGUI based approach my feeling is it will add unnecessary complexity.

Although I admit haven't done much Java GUI development for a long time, so I don't know what other options there are to in terms of frameworks that integrate into Netbeans / Eclipse.

In terms of using a WebGUI such as octoprint, I currently use octoprint on a RPI and although its handy to print across the network, I still much prefer to plug my laptop in and print directly from my slicer when doing some design refinement.

I understand that in a makerspace then laser cutter will more than likely be network connected and makes sense, just don't forget the 1:1 desktop users.

[peteruithoven]

I'd like to know what hakes that difference for you. Do you slice in the Cura desktop app when using Octoprint? We might be able to serve both by also building a desktop app with similar technology using Electron.

[madeinoz67]

Main difference for me is snappiness/responsiveness of the GUI when I'm working and workflow integration.

In regards to Octoprint my preferred slicer is Simplify3D so no Octoprint integration (yet). I still use Octoprint if I want to run unattended prints tho, so has its place.

I can see many benefits of networked web frontend in a multiuser environment like maker spaces, but imho is overkill for a 1:1 use device that only needs to connect and cut.

Electron Definately looks interesting though.

I'd also like to see some form of hook into the GUI for the driver where I can enable/disable GUI elements based on the device driver selected, i.e. the driver I'm writing is for a GRBL engraving device that has no physical control panel except for power on/off and a manual laser enable so would like to have some control elements, i.e. move to home etc. almost like including some of the GRBL Universal Sender like control functions into the GUI, have them already there and drivers will enable/disable/hide/unhide if so required.

Whatever way it ultimately goes I'm sure that its the right step forward :)

[t-oster]

Just stumbeled upon an interactive webbased laser-design software (commercial). Just to give an idea how it could look like: http://www.formulor.de/

[dreydean]

It would be nice to help contribute to Visicut 2! Is anyone here still working on this? I have considered programming the a meteor app due to its connectivity to all things arduino. Also it is a very quick way to program web based apps. It also is all in javascript so libraries like jscad would come in very smoothly.

http://julian.io/meteor-meets-arduino-and-cylon/

[dreydean]

Actually It looks like someone has already begun this so I will work on that. https://github.com/openhardwarecoza/LaserWeb

[peteruithoven]

Another reason to go to a webbased ui: https://github.com/Jack000/SVGnest

[t-oster]

Nice one. Does not need to be webbased though. If someone had some time it would be possible to directly integrate this feature into VisiCut..

[pelrun]

While the Swing GUI form editor isn't available by default in the latest Netbeans versions, it's been compiled as a plugin that still works 100%: http://plugins.netbeans.org/plugin/43853/swing-application-framework-support

[t-oster]

good to know. You have to use the version from the webpage though, the version from the plugin repository does not work for me. Netbeans 8.1RC Finally I can use the latest NetBeans while still editing the GUI.

[pelrun]

Yeah, the repository only serves up the Swing Framework itself, not the form editor (they seem to be named identically...) Downloading from the webpage and installing manually is required.