-
Notifications
You must be signed in to change notification settings - Fork 12
Interface Design
I think SuperSkein should be slick.
I’m talking glossy buttons and tasteful progress bars with messages that fade discretely out of the way and transitions which are fast but pretty between all the displays. Processing has a great graphics library, and I’m going to use it. Perhaps at some point we’ll have to port most of the code to a compiled language for speed, and maybe there should even be a “just slice it” variant that’s all command line and tiny, but there also should be a slick variant that:
- Does everything in pages you can switch through in a stable left-right sequence both with the mouse and keyboard (with hotkeys!)
- Has all the settings available in as few menu pages as possible
- Can display the mesh to be sliced in various ways, including wireframe and solid, with a grid floor in centimeters
- Can display the sliced mesh, both as raw line segments and finished toolpaths, and lets the user either mouse through or keypress through the slices
- Displays progress bars for all the major steps of the slicing progress, so you know how long it’s taking and why.
-
WYSIWYG scale, position, rotate of the mesh just like on modern ReplicatorG; I include this because it’s probably not hard.
What we have now: multiple GUI pages, threading so you get a smoothly moving progress bar that keeps running in the background even if you’re on another GUI page (the slice display scale will be off during a file write at the moment), buttons, and white-on-black which is very important for overall shininess.
I could see having a command-line slicer, which the Processing code is just a wrapper for. It would even simplify making the computationally expensive parts in a faster language like C++ if needed. It does, however, complicate things like progress bar updates and mid-slice layer display. I think that an easy-to-use GUI interface is really the highest priority here, though. We should keep the separation of slicing and presentation in mind while writing the code, but I don’t see a reason to excessively complicate our lives if Processing turns out to be Fast Enough due to JITs and such. If we get down the line and we really do need C++ or C speed, we can port it then, using the Processing prototype as an excellent template.
I absolutely agree— I think in the end we might be much better off creating a command line C++ port after we have everything working and let that be the offering one uses with other tools as part of, for example, building integrated paths between modeling programs and CNC drivers.
So far it really does look like Processing can handle the task— the pathology pumpkin does take a while to slice on my netbook, but you can see the status bar start to update pretty quickly, and from then on you can keep checking back in with it to see how it’s going. Having a sound user experience is definitely a higher priority than speed, so long as speed doesn’t start to get pathologically slow.
GUI.pde is growing up to be a little library of its own at this point, almost worth spinning out if I didn’t hate the text boxes so much.
To use GUI elements by the way, here’s the housekeeping protocol:
- Make sure you have a page or make a new one. Making a page consists of writing a branch for it into the draw() method and making sure the page counter can get to that number.
- Make sure you declare and draw your added element. Each object gets a global declaration, preferably next to the other GUI elements with comments indicating what page it’s on. Calling its display() method draws it, so put that in the branch in draw() that does the display for its page.
- Add handlers; buttons need an if(button.over) statement in the mouseClicked method, text boxes need both that and a doKeys in the keyboard method.
Since Processing is just a thin layer on top of Java, I have to wonder if you can save yourself some effort by using AWT or Swing or whatever the current Java GUI library is.
[edit] Huh. And likewise, I maybe could swipe someone else’s geometry library, like JTS
[further edit] In fact, JTS seems to implement insets/outsets and boolean geometry already. This is great stuff, provided it’s fast enough, and can be used with Processing. It’s LGPL, so licensing isn’t a problem. The only downside I see is if we ever want to port to another language.
Woa, awesome. AWT was a horrible nightmare for me when I tried to use it in high school, but… I was in high school. I’ll give that a look. On the subject of porting, my exceedingly decrepit Compaq laptop behaved pretty adequately with SuperSkein, and while we don’t have all the features in, it seems likely that it would be okay.
Except! My interface code was horribly laggy! So perhaps there’s room for improvement. It’d be nice if I could keep the style though…
AWT looks like it’s probably not much more difficult than setting up threading, but that is an extra class for every /use/ of a button, (I’ve never used function pointers before— seems like they could fix this part) and that starts to be a lot of code to keep after. Having GUI classes with (relatively) lightweight handles the mousePressed and keyPressed methods call seems a pretty clean strategy, even if it means we don’t have automatic support of text boxes with cursors and copy/paste. However, will be working on a config file this week so that on decrepit systems like my Compaq laptop you can bypass all that text field entry for a single EMACS window.
(Side note, the code tested successfully under Ubuntu, yay!)