I don’t know if this has been attempted yet, but here’s a very quick WIP hack together of a small plugin that will allow you to draw a reply in a canvas. I got jealous of google hangouts so I wanted to hack something similar into discourse.
It’s not yet functioning, so I’m throwing it under broken-plugins (it also has pretty primative drawing methods, and starts with some test data already filled in the canvas). I stole a lot of modal view and such from the replygif plugin. Credit where credit’s due.
The broken part is – I’m not quite sure how to shove the base-64 png data across the wire as a file upload just yet (it just prints the data in the console and the compose window for now). Any pointers or suggestions to actually perform an upload would be great!
I was thinking of something like this; had the whole thing coded in my head, or at least how and when specific data moved between client and server/db. Having an optional oekaki input has been the Holy Grail of geekdom and art culture forums, Only phpBB got somewhere with a released mod…that crumbled with time, and the core’s constant advances at that moment.
Those traditional oekaki java applets will cease to load shortly; again, crumbling with time and in this case, closed-source code.
Any current reincarnations kept up to date are closed source (eg, Lascaux Sketch).
Searching for “oekaki” in my stars collection @github returns some attempts in JavaScript and HTML5. I hope they may help in some way to this data transfer and turn it into an actual image. That is where oekaki excelled.
(And as a clarification, I am not asking or expecting the grand Photoshop-like options or any multiple color choices the traditional setups were also known for. Gimmie a line on canvas. All anyone needs, I think.)
Neat feature; we’ve been talking a bunch over at Loomio about a composer which allows for a bunch more forms of communication than just writing text; (ie audio / video recordings, reactions, drawings, etc.), so this is an interesting idea.
If I were looking at implementing file upload I’d have a nice hard look at discourse/mixins/upload.js.es6, and how it’s used and triggered in other parts of the app.
More than happy to help out with a client side only demo if that’s of any interest. Which could then be hardened into a plugin if all went well.
Edit: Although over the top wrt the requirements stated here - tools like this also have save as PNG options. Opening up all sorts of collaborative efforts, in amongst other things, wiki topics.
Well, if any want the grand Photoshop options, ChibiPaint would be the best option to use. Its development is a response to the need for some open source applet similar to the well-known traditional apps like PaintBBS by Shii-chan.
Searching for “chibipaint” in google makes it abundantly clear many resources exist for artists to learn about the app.
And the massive store of more here @ oekaki.pl. Anything with the Program listed as “Chibipaint” was created fully from the app.
I think oekaki mesmerized me by this notion someone can create real works of art without needing an expensive program and a powerful device to do it. It proves the notion all honest artists echo more so now than ever: “Your tools do not make your art.”
I only show this to give example the “max” one can go into this, if they decide to. Art communities thrive with this option; to arrive at the core reason they all congregate in the first place.
Does it need to simulate a file upload? In addition to paste, drag 'n drop and upload, I’m wondering whether the routine that saves images away can’t be overridden to accept a Base64 string directly? Which I suppose is what you are already asking.
Or alternatively, maybe an img tag with base64 src - like this?
Ooh, neato – That could work! My one hesitation is overrunning discourses post character limits with complex/larger images (which is why my impulse says try to figure out uploading raw images via file uploader), but I’ll check it out, thanks!
That’s precisely how I’m playing it at the moment I can also take the base64 data from a canvas, I just want to see if it’s possible to upload on ‘save’ rather than print directly into your editor window. gif screens coming when it’s more refined, swear!
Will do! I’m admittedly a bit of an emberjs and es6 noob here, so any hints as to where to get started for example sets are appreciated, thanks!
Great job! That looks very cool. The creative world is now your oyster.
Yes, when I suggested that I realised it was only suitable for proof of concept. Next step then to pass the base64 string into the image save routine either by fooling the system into thinking you are uploading or dropping a file, or by finding a way of persuading the existing code to accept your string directly.
Just a thought, but depending on how rasteresque you need the drawings to look, you might find it easier, more flexible and work better with the infrastructure in production to use svg paths instead of canvas.
You’d be able to post as character data and even if the paths were drawn on top of a raster image you could add layers so that multiple people might be able to collaborate on a drawing or whiteboard annotation in some sort of pseudo realtime which would be much more difficult and take an absurd amount of bandwidth with raster data and file uploads/downloads.
My primary focus was to enable replying with silly doodles (I’ve got a few more-than-broken experimental branches for figuring out how to upload after ‘submit’ which is my primary focus right now), but I’d be open to PRs if anyone else (who knew a thing or two about SVGs) wanted to bolster the front end to push out more higher quality draw tools.
Actually I wasn’t thinking of something fancy like Illustrator light or that chibipaint thing (which looks really interesting), I think my description got carried away with itself.
I was also thinking of something like that sketch js interface for just that kind of thing. Simple fun line drawings or annotating an image with an overlay.
The reason for my suggestion had more to do with just how much simpler it would be to store the image data as character data embedded in a post instead of as a file upload.
If I can, I’ll install discourse and see if I can test out the idea. I can really imagine this being a fun and useful thing.
I’m assuming you can embed SVG character data in the same way as I’m doing with PNG data, correct? If that’s the case, your method is the same as my current implementation, over canvas.
I’m still concerned for the character limit in a single post, which is why I was looking into uploading, rather than pasting an encoded image inline into the response.
Though as an advantage, I’m assuming that SVG has less data to store, and then would take up less space in your post?
I was assuming that the canvas version was modifying the pixels of an image (or capturing the canvas as a bitmap) and then uploading the file.
If it’s layered on top then that is just like what I’m thinking already.
If I had a WIP: reply by drawing tool I’d do a diagram
I’ll look at your source once I get discourse installed and configured and let you know once I understand it a bit beter.
In short if it ends up uploading the image, svg would be much smaller until a drawing got really complicated. If it is just recording the x and y values of the strokes as number values and saving those number values in the post. Then replaying/redrawing them on display they’d be about the same in terms of filesize.
So it occurs to me that that’s another way to go about it. Have the post just have a data structure of points that are redrawn on canvas when viewed if that’s not how it currently works.
Ok, I have discourse installed and configured, have read the plugin guides and have looked at the plugin. Nice job by the way, it was very easy to read.
While I could be wrong, I’m pretty sure that this is encoding the data in the image. If that’s the case, then every time it would need to save the image for sharing it would need to save the image data somewhere on the server in a binary format. The toDataUrl call is probably doing that in the browser via the canvas context but eventually it would need to be turned into a png in the file upload process, which is a nice format, but not very efficient for stuff like a line drawing.
But we can make this a lot easier and also more efficient without changing the code too much or moving to svg, though I need to figure out more about how discourse saves data and it may still be worth going to svg later.
Essentially what I’d suggest is that every time that you write a new path segment to the drawing context, that you also add the x and y coordinates to an array or tree data structure that gets embedded in the post in some non-visible way.
When rendering we can extract the coordinates and redraw again on the end users client in their canvas context.
I can also take the base64 data from a canvas, I just want to see if it’s possible to upload on ‘save’ rather than print directly into your editor window. gif screens coming when it’s more refined, swear!
