I really like the idea. I am not sure if I like the reality of it as much. This huge QR code looks like it take quite a bit longer to engrave than cutting most boxes. But may be there is a way to fix that. We could try to filter out all settings that are unchanged from the defaults. Yes, this makes it more likely that the link will produce something slightly different. Otoh these links won't survive changes to the generator most of the time.

I also wonder if there is a better way to render the QR code. Lines are much cheaper than engraved areas. Otoh QR codes are made from areas. So I don't know if one really can cheat there.

As for the implementation: This has no business being in drawing.py. The best place is probably Boxes.open() right next to the code rendering the reference bar.

Sorry to destroy your idea of creating an exact replica. The generator is not versioned, so the generation maybe different even with the same URL. The the qr code is also very difficult to read.

But I see the information/data management problem.
The usual download name is boxgenerator.svg. So each development iteration is overwritten or vanishes in the pile of files.
So instead of an URL change the download name to an unique name eg boxgenerator_date_random.svg and add this as qr code or text to enable an user to find the source file?

Well, I think an "exact replica" isn't really needed. The link is even more useful than a exact replica as it allows making changes.

For exact replicas we could add the git SHA1 of the current commit. I don't think I want to add proper versioning to Boxes.py itself. But with the SHA1 people that really care can run the exact version that was used the first time around.

I was wondering the same things, re: the comical size of the QR code and the versioning of the generator.

I like the idea of embedding the SHA1 slug, if you really want to get back exactly. In fact, maybe it's not impossible to create a docker that will happily update itself to whatever revision needed. Might be worth some thought.

For the comical size, keeping only things different from the default will shorten it a lot, but maybe not even enough. I think the ideal thing in terms of size is to use a URL shortener like bit.ly or similar.

So this monstrosity:

Becomes this:

Unfortunately that comes with some infrastructure being somewhere -- either in a commercial service like bit.ly, or somewhere else. Not sure I love the idea of being reliant on some external state somewhere that can be wiped out at the drop of a hat.

On the other, other hand, I could definitely see myself printing the QR code onto a sticker instead of engraving it, so the size isn't as critical in that case.

I found a pretty easy to use URL shortener. It would be pretty easy to run and keep a database around. I can't imagine the database would get that big, but who knows.

https://shlink.io/

It's easy enough to test out locally with:

docker run --rm -it --name my_shlink -p 8080:8080 -e IS_HTTPS_ENABLED=true -e DEFAULT_DOMAIN=cc-i9.local:8080  shlinkio/shlink:stable-roadrunner

and

docker exec -it my_shlink shlink short-url:create 'https://www.festi.info/boxes.py/DrillBox?FingerJoint_angle=90.0&FingerJoint_style=rectangular&FingerJoint_surroundingspaces=1.0&FingerJoint_bottom_lip=0.0&FingerJoint_edge_width=1.0&FingerJoint_extra_length=0.0&FingerJoint_finger=3.0&FingerJoint_play=0.0&FingerJoint_space=3.0&FingerJoint_width=1.0&RoundedTriangleEdge_height=50.0&RoundedTriangleEdge_r_hole=2.0&RoundedTriangleEdge_radius=30.0&RoundedTriangleEdge_outset=1.0&Stackable_angle=60&Stackable_bottom_stabilizers=0.0&Stackable_height=2.0&Stackable_holedistance=1.0&Stackable_width=4.0&Mounting_d_head=6.5&Mounting_d_shaft=3.0&Mounting_margin=0.125&Mounting_num=2&Mounting_side=back&Mounting_style=straight+edge%2C+within&top_edge=e&sx=25*3&sy=60*4&sh=5%3A25%3A10&bottom_edge=h&holes=3&firsthole=1.0&holeincrement=0.5&thickness=3.0&format=svg&tabs=0.0&debug=0&labels=0&labels=1&reference=100&inner_corners=loop&burn=0.1&render=0'

What if there's just a QR code button that downloads the QR code, as opposed to attempting to embed it into the SVG somewhere? Is that better or worse?

I just implemented that here , and you can try it live here: https://boxes-hel7lmi2ba-uw.a.run.app/

It still needs to filter out all the default parameters to make a sane-sized qr code.

I'd just remove the qrcode checkbox if it makes sense to have a button.

By the way, I just learned how to use google Cloud RUN and it seems really cool. I just push to a branch, and it automatically deploys to the https://boxes-hel7lmi2ba-uw.a.run.app server. And what's more, I think it doesn't bill continuously like AWS, only for compute resources used. So it should be really cheap. I think.

Why did you decide to generate QR code in PNG. I think it is necessary in SVG

The layout code stores a link with all parameters. But I'm sure 90% of users do not know that it is there, and most likely will not be able to watch it.

I really liked the idea. I want to offer my vision.

1. QR code must be inserted into the layout. (inexperienced users will be able to use.)
   

2. Also display the QR code through the button separately as in the screenshot above, but for other purposes.

This is very convenient for sending links to colleagues via messengers.
For example: You have a shared computer in your workplace. You don’t have it, you are too lazy, or you don’t want to use mail messengers, etc. on this computer.
You open the QR code, scan it with your cellphone and send it via messenger to a colleague or save it for yourself for the future.

Why did you decide to generate QR code in PNG.
The python library used PIL, which I believe is fundamentally a raster format. At the very least, it was the easiest thing to generate.

I think it is necessary in SVG
I agree, it would be nicer to be SVG. When you say necessary, why do you think it's necessary?

The layout code stores a link with all parameters. But I'm sure 90% of users do not know that it is there, and most likely will not be able to watch it.

Yep. And it's dependent on the output format.

I really liked the idea. I want to offer my vision.

1. QR code must be inserted into the layout. (inexperienced users will be able to use.)
   

What do you mean by 'inserted into the layout'? Do you mean into one of the pieces? In that case, it will be a challenge to figure out how to insert it and choose which piece fits best.

This is very convenient for sending links to colleagues via messengers. For example: You have a shared computer in your workplace. You don’t have it, you are too lazy, or you don’t want to use mail messengers, etc. on this computer. You open the QR code, scan it with your cellphone and send it via messenger to a colleague or save it for yourself for the future.

Oh, on the 'laser computer'. Yeah, that's handy.

I reworked the code a bit. Now the qr code generation is roughly in the right place in the code, next to the burn bar. It doesn't yet get the URL and/or the settings.

My questions:

1. How do I get the current URL from within Boxes.open() so that I can encode it?
2. I'm rendering the QR code directly using Boxes primitives. Turns out I can replace the QR code backend with Boxes primitives. Currently it's being drawn with cut lines, so it looks like this:
   
   How do I modify it so that it will put the output on a 'fill' layer rather than a 'stroke' layer?

Currently, it just outputs a random number so you can see that things change when you reload.
Still needs parameter-pruning obviously.

Also, you can try it live at https://boxes.crome.org/

I've pushed a better qr code generator. It works both on the CLI and web interface. It also gives a QR code for the CLI, even if generated on the web interface.

i'm still a litte unclear on how MOVE works. I need to figure that out.

The qr code dimensions are much more sane.

See https://florianfesti.github.io/boxes/html/api_parts.html#the-move-parameter

OK, this still needs a bit more work to craft this into proper commits. But things are already starting to come together.
Basically have qrcode rendering and short url/cli creation as separate features on which the box generator qrcodes build upon.

Nice! I'm out of town at the moment but will check it out when I get back.

Things are now where the need to be. One more round with the buffing wheel and this should be good to go.

Ok, last few minor issues/ decisions:

Naming .qrcode() vs --qrcode?
Not sure if we need Link and cli on the drawing. Right now it is not that clear which code is which.
Download or view QR code created by button under the generator settings?

Naming .qrcode() vs --qrcode?

Hmm, not quite sure what you mean. Wouldn't --qrcode be on cli and .qrcode() be a method?

Not sure if we need Link and cli on the drawing.

I just put them there as options to talk about. Both could be useful. Any idea what percent of people use the cli? I'd guess pretty low.

Download or view QR code created by button under the generator settings?

Do we need a separate button at all, or is embedded the only thing really needed. My reason for a download PNG button as opposed to embedded only is to print a sticker, which isn't necessarily simple given a light burn file.

Naming .qrcode() vs --qrcode?

Hmm, not quite sure what you mean. Wouldn't --qrcode be on cli and .qrcode() be a method?

May be I should write these post when I am already asleep and they would make more sense...

As I added a .qrcode() method for drawing an arbitrary qrcode this clashes with the qrcode parameter (no matter if it is from the cli or the web UI). So one needs a different name. I currently rename the parameter to qrcode_link whihc solves the problem but is not really great. So a better name would be good - although I am notoriously bad with names.

Not sure if we need Link and cli on the drawing.

I just put them there as options to talk about. Both could be useful. Any idea what percent of people use the cli? I'd guess pretty low.

Yeah, let's just add the http link.
Edit: In the drawing we can just render the cli version if there is no url so the in drawing qrcode works on the command line, too.

Hmm, we could add a command to get the qrcode to the cli. I can look into that, but let's not stress about that now.

Download or view QR code created by button under the generator settings?

Do we need a separate button at all, or is embedded the only thing really needed. My reason for a download PNG button as opposed to embedded only is to print a sticker, which isn't necessarily simple given a light burn file.

Yeah, but showing the qrcode on the screen allows people to snatch it with their phone right away. Some people seem to find it difficult to just save a file from their browser. Otoh I am not sure if I really want two qrcode buttons. The number of buttons to choose from under the generator settings is getting a bit too long.

OK, enough talking...

There is issue

QR code Button generates QRcod to QRcod image link

It must be render=0 inside QRcod image instead of render=3