4 ms·

I hope I'm understanding this right: You're trying to build a web UI that can let you overlay and position a QR code on top of another image? If so, I think ra

I hope I'm understanding this right: You're trying to build a web UI that can let you overlay and position a QR code on top of another image? If so, I think rather than trying to build your own CLI to do this and refresh the image every time, you can do it entirely clientside with something like https://konvajs.org/docs/react/Intro.html https://konvajs.org/docs/react/Intro.html or https://fabricjs.com/ https://fabricjs.com/, storing the QR overlay position and alpha in state. Then once it looks good on the client, you can send that state as an API request to the server for rendering to the final image. (You can probably also just render the finished output on the client directly, but since you already have that part of the rendering in the server, might as well re-use it). i.e. let the user handle the image positioning clientside as state, then send the final params to the server for rendering, e.g. /overlay?x=500&y=300&w=30&h=30&opacity=50. Websockets is overkill and will cause unnecessary complexity. You don't need to sync every intermediate state., just whenever you click "save". Autosave every minute if you must. But why, for something so simple? Positioning the QR code would probably only take a few seconds. PS And if this is for your own use (as opposed to building a service for other users), I should point out you can also easily do this with existing free web-based image editors like photopea.com And as a service, this is pretty similar to what Imgix does already, just without the drag-and-drop overlay GUI. Example here with another QR code in the upper right: https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=https%3A%2F%2Fsandbox-uploads.imgix.net%2Fu%2F1733172845-29226cfcfafabef27fdb8eb7c5f91e1f%3Fblend64%3DaHR0cHM6Ly9zYW5kYm94LXVwbG9hZHMuaW1naXgubmV0L3UvMTczMzE3MjkzNy1iOTBiNmM4Yzg4OTcxOGIxNjBlMTc4NGZmZDc4M2UzYz93PTYwMA%26blend-x%3D1100%26blend-y%3D100%26blend-w%3D200%26blend-alpha%3D75 https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=...

PaulHoule 2y ago
It is likely to turn out like you say. The back end is PIL, I don't know if it's fast enough that I'd want to redraw the image while you drag and drop the QR code but I'm sure it can redraw the thing fast enough to keep up with the arrow keys and if I did want D+D I could have an outlined box stand in for the QR code. I am not so much thinking about this one but the long game that I might want to make 20 things like this in the next year. I might want to pound out 3 in the next month and then I won't think about it for 6 months and then pound out another 7 over the weekend. I don't want to spend another 2 weeks figuring out how to do it again. At work I am used to the "we use so many widget sets that there are seven ways that something might be styled that you need to know about it so management thinks it is pixel perfect" (although it isn't) and that's just one of the traps you can get into to replace fast development with slow development. I'm looking for some plan to eliminate everything slow in developing a bunch of little random apps similar in scope to that QR app. (A similar application I have in mind is a "builder" that can run git and mvn and npm to automatically sync up and build a collection of Java and Javascript projects that comprise a web application. It works great but the output is just as hard to read as the output of "mvn install" and I'd like to be able to simultaneously see THE PROJECT BUILT SUCCESSFULLY despite THESE HARMLESS MESSAGES THAT LOOK LIKE THE SYSTEM LOG FOR A NUCLEAR MELTDOWN. So some kind of UI that lets you from detailed log to various levels of synopsis would be great...)
- solardev 2y ago
  Sorry, I'm not quite sure what "PIL" and "D+D" mean. (Edit: oh, a python img lib and drag and drop). The whole point of doing this clientside is that you're not redrawing anything on the server or sending anything over the wire (while laying out). An image overlay operation is a trivial thing to do in clientside JS, in Canvas, and then once you have it positioned right you just send back the params in a fetch to the server. It makes no sense to redraw the thing every time on the server; that's going to be super janky compared to an interactive canvas. I think this is a perfect case for separating the server and clientside logic. (Edit: Sorry, I edited my previous reply after you already replied. Basically the client would just let the user set the params, and then you'd send it to the backend similar to how you would to imgix: https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=https%3A%2F%2Fsandbox-uploads.imgix.net%2Fu%2F1733172845-29226cfcfafabef27fdb8eb7c5f91e1f%3Fblend64%3DaHR0cHM6Ly9zYW5kYm94LXVwbG9hZHMuaW1naXgubmV0L3UvMTczMzE3MjkzNy1iOTBiNmM4Yzg4OTcxOGIxNjBlMTc4NGZmZDc4M2UzYz93PTYwMA%26blend-x%3D1100%26blend-y%3D100%26blend-w%3D200%26blend-alpha%3D75 https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=.... It wouldn't matter how you rendered the image in the backend, that's up to you, but it frees the user from having to wait for a network roundtrip after every minor adjustment.) And yes, you can easily make this modular enough, especially with a lib, to easily create similar use cases in the future.
  - PaulHoule 2y ago
    Yeah, the client side for just the QR is almost trivial, I don't even think you need the canvas. I can code it up in React pretty quickly, probably not mess with 3rd party components, just write my own HTML and CSS. What mostly concerns me is that one "little" feature in an existing python project (git repository, etc) involves creating another project, opening up another IDE window, etc. Now maybe that React project becomes a sidecar and I build out several mini-applications in it to amortize the investment in maintaining the project, maybe it even grows into the front end for the whole thing. On the other hand I relish the freedom of starting a new mini-app without the complexity and risk that some dependency I add now is the one that I'll be scratching my head over 3 years from now. On top of that I need one button start for the whole system when I guess that's what's bugging me, that a "mini-app" involves having more than one project to deal with, it just seems from a rapid prototyping perspective to be the wrong way. (e.g. I want 10x tools!)

PaulHoule 2y ago

It is likely to turn out like you say. The back end is PIL, I don't know if it's fast enough that I'd want to redraw the image while you drag and drop the QR code but I'm sure it can redraw the thing fast enough to keep up with the arrow keys and if I did want D+D I could have an outlined box stand in for the QR code. I am not so much thinking about this one but the long game that I might want to make 20 things like this in the next year. I might want to pound out 3 in the next month and then I won't think about it for 6 months and then pound out another 7 over the weekend. I don't want to spend another 2 weeks figuring out how to do it again. At work I am used to the "we use so many widget sets that there are seven ways that something might be styled that you need to know about it so management thinks it is pixel perfect" (although it isn't) and that's just one of the traps you can get into to replace fast development with slow development. I'm looking for some plan to eliminate everything slow in developing a bunch of little random apps similar in scope to that QR app. (A similar application I have in mind is a "builder" that can run git and mvn and npm to automatically sync up and build a collection of Java and Javascript projects that comprise a web application. It works great but the output is just as hard to read as the output of "mvn install" and I'd like to be able to simultaneously see THE PROJECT BUILT SUCCESSFULLY despite THESE HARMLESS MESSAGES THAT LOOK LIKE THE SYSTEM LOG FOR A NUCLEAR MELTDOWN. So some kind of UI that lets you from detailed log to various levels of synopsis would be great...)

solardev 2y ago
Sorry, I'm not quite sure what "PIL" and "D+D" mean. (Edit: oh, a python img lib and drag and drop). The whole point of doing this clientside is that you're not redrawing anything on the server or sending anything over the wire (while laying out). An image overlay operation is a trivial thing to do in clientside JS, in Canvas, and then once you have it positioned right you just send back the params in a fetch to the server. It makes no sense to redraw the thing every time on the server; that's going to be super janky compared to an interactive canvas. I think this is a perfect case for separating the server and clientside logic. (Edit: Sorry, I edited my previous reply after you already replied. Basically the client would just let the user set the params, and then you'd send it to the backend similar to how you would to imgix: https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=https%3A%2F%2Fsandbox-uploads.imgix.net%2Fu%2F1733172845-29226cfcfafabef27fdb8eb7c5f91e1f%3Fblend64%3DaHR0cHM6Ly9zYW5kYm94LXVwbG9hZHMuaW1naXgubmV0L3UvMTczMzE3MjkzNy1iOTBiNmM4Yzg4OTcxOGIxNjBlMTc4NGZmZDc4M2UzYz93PTYwMA%26blend-x%3D1100%26blend-y%3D100%26blend-w%3D200%26blend-alpha%3D75 https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=.... It wouldn't matter how you rendered the image in the backend, that's up to you, but it frees the user from having to wait for a network roundtrip after every minor adjustment.) And yes, you can easily make this modular enough, especially with a lib, to easily create similar use cases in the future.
- PaulHoule 2y ago
  Yeah, the client side for just the QR is almost trivial, I don't even think you need the canvas. I can code it up in React pretty quickly, probably not mess with 3rd party components, just write my own HTML and CSS. What mostly concerns me is that one "little" feature in an existing python project (git repository, etc) involves creating another project, opening up another IDE window, etc. Now maybe that React project becomes a sidecar and I build out several mini-applications in it to amortize the investment in maintaining the project, maybe it even grows into the front end for the whole thing. On the other hand I relish the freedom of starting a new mini-app without the complexity and risk that some dependency I add now is the one that I'll be scratching my head over 3 years from now. On top of that I need one button start for the whole system when I guess that's what's bugging me, that a "mini-app" involves having more than one project to deal with, it just seems from a rapid prototyping perspective to be the wrong way. (e.g. I want 10x tools!)