John Lauer architecturally what is the rationale for allowing widgets to access the ondropped

CAD & CAM Tool Chain ChiliPeppr
1

@jlauer architecturally what is the rationale for allowing widgets to access the ondropped event in parallel to the gcode list widget? I’m just looking at potential routes for ‘roughing up’ the rendering and also for potentially increasing the granularity of the moves for autolevelling; but I can see an issue with circularities and inefficiency due to repetition.

logically the approach I was looking for would be this:

  1. gcode file is imported by the drag drop widget
  2. the gcode list parses it and cleans it up.
  3. the cleaned code is published
  4. the renderer subscribes to the pubsub and decides on the granularity of the render. then renders.

problem I see is maintaining the gcode line numbers properly associated with the renderer’s lines. but this should be feasible.

for the eagle import widget I see no difference. the board will be rendered by the import widget, but the toolpath would be rendered just like the gcode list.

for autolevelling, my feeling is that the workflow would be:

  1. import using the board widget.
  2. board is rendered
  3. autolevelling done
  4. gcode is first pass generated and then regenerated with interpolated coordinates according to a specified granularity. I think this should be calculated by an heuristic that takes a look at the delta in height at the measured points.
  5. autolevelling data is then pushed to the granular gcode list
  6. gcode list pushes the gcode for rendering.

tia
Justin

2

That’s kinda what I’m thinking too

3

I think everything you described sounds spot on. With regard to the ondropped, the reason that’s available as pubsub is that when you drop an Eagle file, the Eagle widget has to get a chance to investigate it first by subscribing to the ondropped pubsub at a higher priority. If it sees that it is a BRD file then it returns false which makes the pubsub stop propagating to other widgets. (See amplify.js docs to understand how the pubsub works). If you drop an SVG file, that widget is subscribed direct to ondropped as well at a high priority so it can intercept SVG’s and not let them propagate to the Gcode list.

As for Gcode then, I think your approach makes sense. I do think today that Gcode list gets it at same time as 3D viewer. The Gcode widget can/will modify the Gcode and thus it republishes it sometimes to the whole workspace. This can get confusing, but it was done to try to keep a loosely coupled framework across the widgets.

I do think one longstanding problem is the Gcode widget stores it’s own last-imported file in localstorage and the 3D viewer stories it’s own copy of last-imported. Although that’s not really related to your post.