KittyCAD / modeling-app

The KittyCAD modeling app.
https://kittycad.io/modeling-app/download
MIT License
354 stars 29 forks source link

gltf-standard is two files, that causes some UX problem for exports #1151

Closed Irev-Dev closed 5 months ago

Irev-Dev commented 9 months ago

https://github.com/KittyCAD/modeling-app/assets/29681384/0feb40f9-2209-4cb2-8286-c02b8d53f32c

like I said above fix is awaiting a promise so the pickers open up one after the other, but I'm not 100% sure about this, Rolling with it because it's better than before but

  1. two consecutive file pickers is a weird experience
  2. in the gltf json there buffers [ {uri: "output.bin"}] so if we let the user name the bin file something else it will likely break.

Fixes are

  1. skip picker for gltf standard (but would be weird it not having picker when every other format does
  2. remove gltf-standard as an export option
  3. zip both files together

I think 3 is the best

lf94 commented 9 months ago

Yea, 3 is best here also because some other formats like obj can reference other files too within it. It's nice if 2 or more export files default to zip, otherwise their original format.

Irev-Dev commented 6 months ago

@lf94 is resolving this issue/ziping gltf-standard something you would be interested in doing?

lf94 commented 6 months ago

Consider me interested :)

Irev-Dev commented 6 months ago

Awesome!

Note: changing this will break the exports of each format should work e2e test, shouldn't be too hard to fix up and we can cross that bridge when we get to it. But there's a whole

if (output.type === 'gltf' && output.storage === 'standard') {
// wait for second download

that will need to be removed.

lf94 commented 6 months ago

Thanks for the heads-up!

lf94 commented 6 months ago

This'll require a change somewhere on the server side to return a zip when appropriate.

jessfraz commented 6 months ago

No we want to handle it client side after we get the response.

lf94 commented 6 months ago

Oh ok - I initially thought about doing it that way, but quickly I could see every single client needs to then implement or include a zip package in order to offer the same functionality which doesn't seem great.

Are we concerned about returning a zip from the server too resource intensive or adding a complication over there?

jessfraz commented 6 months ago

We already use this endpoint as is in the diff viewer and cli and in text to cad ui, changing the whole endpoint just for modeling app makes no sense then all those apps would have to unzip to keep the same functionality

jessfraz commented 6 months ago

I’m concerned about breaking people

lf94 commented 6 months ago

Gotchya gotchya. :slightly_smiling_face: Thanks for filling me in! I think it would make sense but it's a good argument to not create unnecessary toil at this stage :laughing: (or break people :upside_down_face: )