Ability to CSV export a cutting diagram

[mauriciobellon]

Hi @bbeaulant,

What would you think about exporting a csv of a generated cutting diagram information? Do you recon it would be possible?

For instance I use the information on the generated diagram to input into my excel sheet to precisely calculate costs.

some info that I am using now:
number of parts
quantity of material
list of parts that belongs to the given plan
the leftovers that goes to another sheet that holds all material I have stocked.
total length of cuttings
number of cuttings
Overall efficiency

I am doing it by hand for every material in the parts list.

Another improvement would be to quickly import csv with materials quantities and dimensions that one have stocked, it could allow for quick management of the leftovers and warehouse stocks.

I will work on this features cause it will make my life so much easier.

If you think it makes sense I can send you once I make it work.

Thanks

[mauriciobellon]

BTW I gave some tough about our last conversation:

To be honest, currently, I don't know. Core part of the code is done by myself, I like the freedom it represents and that's why I love working on this project. And I think that I must work differently if one more person work on the same portion of code.
What would you have liked to do on this project?

I see that it can change things, will reflect on that and get back to you.

Some of the issues that people are raising here are related to Windows compatibility, which is my understanding that you don't use. If you care to fix those but can't manage it, then you can flag me, and I would be happy to take a look. We can start small. :)

In the beginning, I may have some questions about the app's deep internals that may be trivial to you, but I'll catch up quickly.

That said, I respect you if you decide to keep things as they are.

Cheers

[bbeaulant]

Hi @mauriciobellon,

If you can explore this issue, it can help us, yes!

What would you think about exporting a csv of a generated cutting diagram information?

I think CSV is a flat data format but cutting diagram data needs a tree to be properly represented. JSON or something like that would be better, but unlike CSV, the json data structure might be too specific/proprietary to meet all users' needs. So I think it's not a good direction to make a native exporter to OpenCutList for cutting diagrams as much as for Estimate modules for that matter.

To solve all of those needs it would be better to imagine a more global solution. Like creating an API and a system of user add-on in OCL to allow every user to write it's own code to extract what he want with the format he want without changing the core code. But this is not a priority at the moment.

Currently, all our forces are focused on rewriting all the cutting diagram code.

[mauriciobellon]

I think CSV is a flat data format but cutting diagram data needs a tree to be properly represented. JSON or something like that would be better, but unlike CSV, the json data structure might be too specific/proprietary to meet all users' needs. So I think it's not a good direction to make a native exporter to OpenCutList for cutting diagrams as much as for Estimate modules for that matter.

My intent was to make a way to export some relevant information for cost estimation of labor, didn't really think about exporting it all.

That said, I see the problem with using CSV here.

...
list of parts that belongs to the given plan
the leftovers that goes to another sheet that holds all material I have stocked.
...

To solve all of those needs it would be better to imagine a more global solution. Like creating an API and a system of user add-on in OCL to allow every user to write it's own code to extract what he want with the format he want without changing the core code. But this is not a priority at the moment.

That feature would be incredible in deed, it would put OCL on another level. I think a great deal would go to make it user-friendly.

Currently, all our forces are focused on rewriting all the cutting diagram code.

I notice you've been busy on that, may I ask why are you rewriting it? If you need a hand there, just ask! :)

[bbeaulant]

My intent was to make a way to export some relevant information for cost estimation of labor, didn't really think about exporting it all.

Yes, I understood. But I don't like to do things halfway.
A new feature must solve the whole problem or not exist. It's easier to maintain.

I notice you've been busy on that, may I ask why are you rewriting it?

To be able to go further. Write new algorithm in C++ for better performances and be able to solve nesting problems 😉.

[mauriciobellon]

Yes, I understood. But I don't like to do things halfway.
A new feature must solve the whole problem or not exist. It's easier to maintain.

Agreed, you are totally right to think that way.

I just intend to do that for my use because I spend most of the time doing cost estimation and that manual process kills many hours every month. So right now for my use case, it is cheaper to have that simple implementation than none. That said, the full implementation of an API would be great. Maybe 8.0 🤞.

To be able to go further. Write new algorithm in C++ for better performances and be able to solve nesting problems 😉.

Incredible man, excellent work. I looked at your YouTube before your answer to find something, thanks for sharing. :)