Update to Vue3

[Bouni]

As Vue2 is in maintainance mode, it would be a good idea to update to Vue3 (despite I've never done that before and have no idea how much pain that is 😅)

[ModischFabrications]

Same problem here... I migrated to Svelte for the next project and didn't work with Vue again afterwards. If I remember correctly there should me a migration tool, might be worth checking that one out. Probably won't fix everything, but it's a start.

[Bouni]

Yes, you're right, ther's a migration tool. I already watched a youtube video about it and it seems not all to hard to do. I've never used svelte but have a few side projects done with vue3 and I really like it so far. Is Svelte better that Vue?

[ModischFabrications]

Good question, better ask someone that knows vue better than me :D For me the workflow seems a bit better developed and more robust, especially with the full integration of sveltekit, but you do get fewer add-ons.

[Bouni]

I did some tests and its more of a pain in the rear than I expected. A lot of dependecies that require vue2 and do not have a suitable vue3 package. Especially the vue-bootstrap package (there's vue-bootstrap-next but its not production ready ....)

The frontend is not too complicated, so how do you like the idea of a complete rewrite in vue3 + vite + a nice frontend framework?

I always wanted to do a project with Naiveui

Let me know what you think about such a rewrite

[ModischFabrications]

Damn, too bad, guess we are stuck with Vue 2 then for the current development. Not sure about the amount of work needed. I don't have much time, but you are obviously very welcome to contribute to the project. I'm open to new frontends, couldn't hurt to have an alternative. Do you want to do it here "in place" or start a completely fresh project?

[Bouni]

I'm not sure what way to go to be honest. I looked into naiveui a bit more and it seem a bit heavy for such a small project. Maybe plain tailwindcss or something simmilar would absolutely sufficient!?

I guess I do a quick experiment in a branch and see if this works out.

Do you have anything you defenitely want to keep as it is now? These are the things I would like to change:

• vue2 -> vue3
• npm -> pnpm (way faster)
• vue-cli -> vite (also much faster)
• pinia (having a store could help with caching #53)

[ModischFabrications]

Sorry, missed your question here during the deployments.

I heard good things of both pnpm and vite and vue3 is obvious, so no protest from me there. pinia I know nothing about, but I can't argue with the results if it works.

For "looks" I'm happy tailwind, I'm currently evaluating it in another private project and it seems easier than raw CSS while staying very flexible. I'm also open to more opiniated frameworks like https://daisyui.com/ , which could make it even easier, because there is little "new" styling needed here.

[Bouni]

Uhh, never heared of DaisyUI before but it looks very nice and lightweight 🤩 I did a few experiments with primevue/talwind and its not very intuitive so I probably do a new attempt with DaisyUI then. But as always, this will take some time (kids take a lot of my spare time 😅)

[ModischFabrications]

No hurry, the current release seems stable :)

On Mon, 5 Feb 2024, 13:22 bouni, @.***> wrote:

Uhh, never heared of DaisyUI before but it looks very nice and lightweight 🤩 I did a few experiments with primevue/talwind and its not very intuitive so I probably do a new attempt with DaisyUI then. But as always, this will take some time (kids take a lot of my spare time 😅)

— Reply to this email directly, view it on GitHub https://github.com/ModischFabrications/CutSolverFrontend/issues/65#issuecomment-1926874604, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGB2KOA7VPAO2ZA3GA2JBR3YSDFJ3AVCNFSM6AAAAABCIWPTE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRWHA3TINRQGQ . You are receiving this because you commented.Message ID: @.***>

[Bouni]

I have a early draft (just a design skeleton, no functionality yet),

[ModischFabrications]

Great progress 👍🏻 My initial concerns: Kerf: Tooltips or a small (i) might be better than the text preview, I would keep a sensible preset. The new row should probably also be separated a bit better, I noticed that my way of building it inside the table is difficult to implement. The solve button should probably also be larger.

Feel free to experiment with the layout, I can't say that my initial draft of the UI is great.

Adding import & export buttons might be useful as well.

[Bouni]

Yes, I noticed that but as I said this is more of a quick shot to see if Tailwind/DaisyUI feels right (and it does 😄 )

I'll post more screenshots as I progress. feel free to give thoughts so that we end up with a equaly godd or better UI than the current one!

Import/export is already on the list.

[Bouni]

Ok, I have a first version up and running that includes import of CSV data, export to PDF and export to CSV 🥳

This is imported from CSV:

Thats the Result:

That's what the exported CSV looks like: (Not ideal as it does not include the names but I strugle to find a good way to include that in an CSV ....)

An this is the exported PDF:

I plan to allow the user to include some metadata, such as project name, stock name and maybe some calculatiosn such as used material, efficency ...

That will then also be shown in the PDF (not sure how to put that into the CSV to be honest)

[ModischFabrications]

Great progress, I like the new layout! Colors are a bit muted and the low contrast for the text makes it a bit difficult to read, but that's something for a final pass at the end.

The import button might be better placed above, it's easy to mistake for an export. Putting the input over the table would also give a better reading direction now that I think about it.

Putting the names into the CSV is not that important. Human users will use the PDF anyway, I'm not actually sure what the use case for that one is.

More stats for the result is a good idea, but I'm not sure how big the impact for a user is. I thought about listing the cutoffs before, but I never really had a use for that.

I guess the PDF can be a simple copy of the output segment for now. Another idea might be to export something like a measurement list with the sums, so a user can mark the whole bar at once and cut sequentially. Not sure how the results can be used best, need to think about it. Additional info should at least be a date and name/link to the tool. Name and author for the PDF could be requested in a simple popup, do check if/what the export lib writes into the PDF metadata.

[ModischFabrications]

Oh, and something to think about: I feel like the solver backend functionality could be implemented within the frontend with little effort and similar performance. Using something closer to the metal like web workers would probably beat it, but I haven't done something like that yet. Multi-threading will probably be a deciding factor.

This would decrease the complexity massively and allow hosting as a static page without any external dependencies. This could also enable usage as a SPA/PWA to be used offline. At first development I actually thought about building a native app but decided against it, but something like this should work everywhere without additional effort.

[Bouni]

You're right with your points, concider this more of a Draft. I know that there's a lot room for improvements.

Colors are a bit muted and the low contrast for the text makes it a bit difficult to read

I have not yet tweaked the colors, I just used two predefined daisyui color schemes

The import button might be better placed above, it's easy to mistake for an export. Putting the input over the table would also give a better reading direction now that I think about it.

I totally agree

Putting the names into the CSV is not that important. Human users will use the PDF anyway, I'm not actually sure what the use case for that one is.

I think the same, I just added it because someone in the issues asked for it.

More stats for the result is a good idea, but I'm not sure how big the impact for a user is.

For my project thats interestig as it requires different stock types and that way I have one PDF per stock type in the end which makes it easy to pick the right sheet for cutting the stock.

I thought about listing the cutoffs before, but I never really had a use for that.

We can add that later on if somebody actually needs it in my opinion

I guess the PDF can be a simple copy of the output segment for now. Another idea might be to export something like a measurement list with the sums, so a user can mark the whole bar at once and cut sequentially. Not sure how the results can be used best, need to think about it.

Isn't that what the PDF at thme moment looks like? Maybe I don't get what you actually mean 😅

Additional info should at least be a date and name/link to the tool. Name and author for the PDF could be requested in a simple popup, do check if/what the export lib writes into the PDF metadata.

Good idea!

Oh, and something to think about: I feel like the solver backend functionality could be implemented within the frontend with little effort and similar performance. Using something closer to the metal like web workers would probably beat it, but I haven't done something like that yet. Multi-threading will probably be a deciding factor.

This would decrease the complexity massively and allow hosting as a static page without any external dependencies. This could also enable usage as a SPA/PWA to be used offline. At first development I actually thought about building a native app but decided against it, but something like this should work everywhere without additional effort.

True but I really like the approach as it is because I initially thought to add a CLI to the backend that allows to send a CSV to it and return the PDF. The stock data and so on could be send along as POST data I guess.

But your SPA idea has its own benefits ....

[ModischFabrications]

Sorry for the late comment, life is busy.

PDF cuts

The problem is that each segment is a new "relative" position, which leads to cumulative errors when aligning over and over. A simple solution would be to(also) show the cut positions relative to the start, similar to just placing a tape measure next to the bar. Both approaches have their use, they could probably be shown at the same time.

CLI

I also had that thought in the beginning, but packaging for Python isn't great and I had little benefit from a offline solution. CLI usage would probably also be equal effort with a TS version via npx.

"online" CLI with calls to the backend has little benefit, because your local computer will probably be faster than the small OCI instance here,

[Bouni]

Sorry for the late comment, life is busy.

No worries, same here 😅

In my opinion marking a stock with cut marks and then cut all in one go is not very precise, at least if one needs precision for woodworking etc. But there are use cases that could benefit from such measurements, we might make it selectable as an option so that the user can output what fits his needs the best ...

I'm just not godd at writing JS/TS so python feels more comfortable to me.

I never mentioned before you can test the Vue3 branch here: https://devcutsolver.bouni.de/

[ModischFabrications]

cut marks

Fair. I'm fine with leaving it as it is, just something to think about.

not comfortable with JS/TS

Same, that's why the current backend is Python. I could look into creating the integrated worker for local usage if you want to keep working on the frontend. I think it shouldn't be too difficult to translate the python code over.

Cutting out the backend portion should move development as Cutsolver v2/SPA into a new repo.

test

Nice, I like it, great work!

Some feedback and a summary of the previous things:

1. 69 happens here too

2. Part names should probably be empty and optional, similar to the stock name above
3. Import above?
4. Quantity should start at 1, cant reset it to 0 anyway
5. Length shouldn't have a preset, can't make an assumption
6. matrial has a typo, that sentence also seems a bit ..off? Maybe "3 Stocks needed"
7. Name, Quantity, Length are easy to miss, stock settings feel like the column titles. Maybe more spacing and stronger emphasis?
8. Github link should probably link here instead of me
9. (i) feels a bit outdated and should definitely mention your work! Footer can also be extended
10. CSV export has a generated name
11. PDF exports additions

PS: 2x4 is an interesting suggestion; kind of ironic seeming as we probably both never used one here in Germany ;)

[ModischFabrications]

FYI: I found a commercial solution that offers pretty much the same thing, just closed source and pay to play after a certain limit.

Great for comparison though ;) https://www.opticutter.com/linear-cut-list-calculator

[ModischFabrications]

FYI: API will change a bit during https://github.com/ModischFabrications/CutSolver/pull/71 , but integration shouldn't be that different. Might actually get easier to draw outputs without carrying job over, will see