Allow dragging pieces position in final cutting diagram

[Pereitor]

It would be nice if we had the ability to drag and move (and maybe rotate?) the position of pieces in the final cutting diagram. Sometimes there's stores they require, for instance, the smaller pieces to be arranged near the borders or so of the raw material board, and usually it would be a mere matter of selecting a group, or a piece, and moving it to an edge. Instead, I've had to hand-draw my custom cutting diagram based on the one suggested by OpenCutList but with this slight modifications. This is the only single feature that I really miss in OpenCutList and it would mayke it even superbier.

[bbeaulant]

Hi Pereitor,

Can you provide a graphical use case of this request ?

Regards

[Pereitor]

Hi Boris,

I don't know if this willbe useful enough but here it goes:

This is the cutting diagram of some work I did yesterday.

This is a standard 2440x1220 plywood table with taped edges. There's two tasks I need to accomplish here:

1. Maximize the use of the existing masking edge, to allow remasking or re-edging it as much as I can.
2. Arrange some pieces in the order required by the store, which requiere the smoller/thinner pieces to be as closer to the edges as possible.

As you can see, to start with, all the pieces on the right side could be moved to snap their borders to the right edge of the board.

The purple color group could me moved from the vertical middle of the board to the bottom of the sheet, as they require also the small pieces to be in descending order from larger to shorter (they would get one larger 666+734 mm piece, then cut it in J and K).

The blue group could be dragged to make it snap on top of the purple group after moving it to its new position, then each of its parts (E, I, C, D and A) to make them snap to the right edge of the board, instead to B's right side.

The L piece (orange arrow) could be moved to the right for the same purpose, also.

It's not displayed on the picture, but the B piece could be moved also to the bottom, to take advantage of the edging.

This way there would be gaps of raw material between top and bottom half parts of the board and between B and the small pieces, which could be desireable in some scenarios.

I hope it is clear. Don't hesitate asking for further clarification in case of need ;)

Many thanks for showing interest ;)

[bbeaulant]

Ok, I understand your need. But this is really a special case that is different from "common" strategy.
This case prefer pulling parts on edges instead of minimizing leftovers.

Yes this is not the current strategy of OpenCutList that stacks all parts from one corner of the sheet.

Globally we won't be able to reach your goal.
We think that OCL is the best if it save the minimal thing to reproduce the exact same result each time. Storing each part position is too complexe to achieve correctly our first goal.

Cutting diagram is more a guid than a must follow rule. Some "tweak" like that could be done in live, no ?

[Pereitor]

Ok, of course it's up to you, but what I mean is not changing anything of the current strategy or algorithm whatsoever, but just allowing the final arrangement to be changed manually after it's been applied, allowing the pieces to be clicked and dragged / moved around to the desired position.

I can understand that many users may have this need of allowing for small modifications for whatever reason, but oh well.

Maybe this could be accomplished also using a different approach, like for instance exporting it to SVG or so and editing it in the proper application...

[bbeaulant]

but just allowing the final arrangement to be changed manually after it's been applied

Yes, but I'm pretty sure that in this case the majority of users want to save their customization :)
And this is where it breaks our first goal of simplicity of the tool. This is a choice of where stop simplicity and start complexity :)

I know that this could be a limit in some case, but I think that it's an advantage in the common use.

Maybe this could be accomplished also using a different approach, like for instance exporting it to SVG or so and editing it in the proper application...

Currently print to PDF and play with it :).

[Pereitor]

I want to make it clear in advance that I show my greatest respect to the authors of this superb piece of free software and that of course I'm not questioning their decisions of what they choose to do or not.

That said, I can't understand the reasoning about "breaking the simplicity of the tool", "adding complexity" or "being a limit in some case". The current functionality stays the same. Noone is forcing any user to click on the pieces on the diagram and/or to drag and move them out of their position. Obviously, functionality would stay exactly the same for those who choose not to use it and/or don't have a use for this.

I can understand whatever other reason, like "we prefer to spend our time developing other features" or "fixing bugs" or "this should be a paid feature", though.

Printing to PDF and "playing with it" is of no help to me, also, as I don't have a PDF editing tool and/or the blocks are not freely editable.

Anyway if it's not going to be addressed, I think it's probably better to close this feature request than to keep going on this sterile conversation.

Thanks for all again ;)

[bbeaulant]

I want to make it clear in advance that I show my greatest respect to the authors of this superb piece of free software and that of course I'm not questioning their decisions of what they choose to do or not.

I know. Thanks.

Noone is forcing any user to click on the pieces on the diagram and/or to drag and move them out of their position.

Yes, no one need to use it, but adding the moving part feature without saving custom part position is not really a complete feature that make sens.
And saving each part position is not suitable for our main goal of "easy to reproduce".

Moving parts in cutting diagrams is not just to moving rectangles on the screen. All the result proposed by OCL should stay coherent. Cuts (count, position and total length), saw kerf (space between parts), etc need to follow those changes.
Then it's exactly as recomputing a new cutting diagram with more parameters and constrains.

This is where the "complexity" will starts. And complexity is never good in a software for developper as for users.

[mobilarte]

As programmer of the cutting diagram algorithm let me add a few remarks.

• the cutting diagram is not stored, but recomputed every time. A modified diagram would need to be saved. What happens when you modify a cutting diagram and send the drawing to another person? This is where the complexity increases dramatically and adding a feature that only works in very special cases would be a bad choice.
• in your example, the smaller parts are along an edge as soon as you have cut the first two guillotine cuts, but obviously not along an outer edge. In most cases, one prefers material from the inside of a panel rather than the edges. There are some cases where one would like to move parts closer together than the cutting algorithm does, even if that means more waste. To achieve this, you can always compute a cutting diagram by selecting only the elements you would like to have grouped together.
• we already have a feature request (issue Add a way to force grain continuity in cutting diagram #371) that is far from trivial to solve. We will certainly give that one a much higher priority.

[Pereitor]

Regarding the complexity issue, yeah, of course I understand the level of technical that addressing this feature would require. I thought you were talking about user experience complexity.

And about the saving/modifying diagrams and sending it to other people... Well, it wouldn't need to be saved, as currently. You could just modify it for your own needs. I don't see this as a problem, as the arrangement of the pieces in the cutting diagram can currently be altered by a number of means that are user-customizable, like chosing the certain corner where the arrangement starts, chosing the level of optimization used by the arranging algorithm, chosing to group closer similar pieces or not, chosing an horizontal/vertical arranging strategy, making modifications in the 3D design, or whatsoever. I would treat or consider moving pieces in the cutting diagram exactly as changing any other of the parameters I mentioned. If you "mess" with things, obviously you are going to get a different result than staying with the default parameters.

I already explained before the reasoning behind my suggestion/request, @mobilarte . Of course I understand the "in most cases" case you mentioned (even if it could be argueable that there should be such a "most preferrable case"); I do it in advance. Of course, what I'm providing is examples of the OTHER CASES or countercases where my request could be taken benefit of.

Regarding the requests with much higher priority, of course I understand that, also, even if I don't understand or have a need for the one you provided.