Proposal: Make bitmap drawing it TW more prominent

[felixhayashi]

I recently discovered that free-hand drawings are possible out of the box in TW – yes, can you imagine, I didn't know.

This is such an important feature (especially for students who need to take notes), I wish I had known that I could create drawings in TW while I was sitting in lectures. I used to be annoyed when the lecturer drew something on the board because this meant I had to switch from TW on my Laptop to analog Pen & Paper.

I would suggest the following.

• Add a "Create drawing" button to the core that is shown in the page toolbar (not per default, of course)
  • This button creates a draft where the tiddler type is set to png
  • This button creates a color field in the draft tiddler (see below)
• At the moment, only yellow is used as color. It would be highly convenient to reuse the color field to switch colors in the editor.
  • So if I want to draw in blue, I simply change the color field to a blueish color.

[tobibeer]

It would be highly convenient to reuse the color field to switch colors in the editor.

You may be interested in Adding A ColorPicker For Editing Images @ tb5

[felixhayashi]

:+1: @tobibeer Now we are talking! Exactly what I was looking for.

That thing should go straight to the core (with a page button "create new drawing" as described in the OP).

Did you ask @Jermolene about integration. Honestly, it is such a great feature to have a simple drawing editor in TW and it requires only such a minimal codebase and is greatly needed by all people who need to do sketches in classroom or elsewhere!

[tobibeer]

@felixhayashi, mhhh, haven't asked yet... I think decent image editing requires slightly more than a color picker.

Deciphering the core to arive at the above linked solutution turned out to be slightly more complex than I had anticipated.

[twMat]

A bit odd for me to say, but I think the drawing feature should be a plugin :-O

I really would love a decent TW drawing tool - like @felixhayashi also particularly for lecture notes - but for it to be useful it would need more functionality. It's a bit a matter of "at least these features or it is basically useless". It is particularly critical that I, likes surely many others, use my laptop touchpad to draw with so the precision is sucky-sucky.

Off the top of my head, I'd say these are the minimums;

• rectangle tool
• lines
• typing
• highligting
• probably color picking or black as default (btw, cool @tobibeer !)
• erase e.g rectangle section

So, yeah, that's a bit demanding and probably would take quite a few kb's - which is why I think it would be better as a plugin.

BTW, imagine making icons etc for the TW itself with this. And how about a package with premade "stamps" depicting TW elements (a "tiddler", an empty "tabs list" etc) for making quick TW mockups.

[twMat]

BTW, there are quite a few drawing or diagramming tools out there. Quick search;

• http://www.findbestopensource.com/tagged/Whiteboard
• http://modeling-languages.com/javascript-drawing-libraries-diagrams/
• http://www.slant.co/topics/28/~javascript-drawing-library
• http://www.learningjquery.com/2015/05/7-awesome-javascript-libraries-for-drawing

Oh, and we shouldn't forget that @inmysocks is experimenting with these things!

[felixhayashi]

A bit odd for me to say, but I think the drawing feature should be a plugin :-O

o_o @twMat ! I expected @pmario to say that! @pmario, since Mat said it should be a plugin, maybe you can enter the debate on my side instead?

I really would love a decent TW drawing tool for some of my TWs but for it to be useful it would need more functionality.

First: I disagree.

1. It hurts in no way to make a sweet tiny 0kb primitive drawing editor available in tw.
   • People who argue that the core get's bloated have no argument
     • It consumes no additional space in the core (except ~20 lines of wikitext).
   • People who argue it bloats the GUI have no argument:
     • It is not activated in the GUI per default (no button in the toolbar).
2. If nobody is offended by adding it, then the question is merely, is it useful?
   • I find it highly useful. It has enough features to digitally reproduce what a lecturer drew on the blackboard in a classroom setting.
     • thickness of the pen
     • colors
3. If somebody needs a more advanced editor, then he/she should indeed install a plugin. Yes. But it makes sense that the core provides a minimal editor to draw something. Why not??

See the christmas cards people drew using this minimal editor already:

https://twitter.com/TiddlyWiki/status/677410266586460160

[pmario]

o_o @twMat ! I expected @pmario to say that! @pmario, since Mat said it should be a plugin, maybe you can enter the debate on my side instead?

:)) ... yes, what Mat expects, should be a plugin. ... but what TW core offers should be as lightweight as possibly useful. .. Which imo is tobias's extension with some UI improvements ... and (my wish) a very basic 2 step undo.

Everything else should be a plugin.

[tobibeer]

and (my wish) a very basic 2 step undo

I was thinking as well that undo would indeed be important. However, here we're in edit-mode and I expect there to be a lot more undoing going on than for an actual commit to the tiddler store of something that is not a draft.of something anymore ...so I was hoping we could leave drafts out of the picture for #2030. But I guess, we should possibly consider two operational modes of an undo feature:

1. undo changes to non-drafts
2. undo draft edits

[twMat]

(Somebody drew that in TW??? That's impressive.)

@felixhayashi wrote

• It consumes no additional space in the core (except ~20 lines of wikitext).

1) I didn't realize it is that small 2)...but would the additionally needed features be that small too?

One thing that would not cost anything but that woudl make the current drawing function more useful is if one could make the editing canvas bigger in some smooth way. It is currently limited by the size of the editview tiddler (not to mention the minimal default size). It'd good to have an enlarged but "zoomed in" editing canvas so that you can clumsily draw big things, and then when you go to viewmode it is zoomed out so the resulting image is decreased to fit the tiddler. Much harder to draw finer details than to see them.

Come to think of it, a probably-fairly-easy-to-make-plugin would be a "button" in either editmode or viewmode to quickly switches type into a predefined image type (is .png the best for TW?) and a predefined canvas size for the canvas, or two togglable sizes; full tiddler size or full browser size. It could also hide the [Preview] button which is pointness for drawings.

[felixhayashi]

:)) ... yes, what Mat expects, should be a plugin. ... but what TW core offers should be as lightweight as possibly useful. .. Which imo is tobias's extension with some UI improvements ...

@pmario Exactly my opinion. I mean eventually, my proposal is just about making something prettier that is already there.

and (my wish) a very basic 2 step undo.

That would be very useful! I hope it is doable.

2)...but would the additionally needed features be that small too?

Should be. Not so sure about the undo though. But generally speaking it is far far below a normal lib.

It is currently limited by the size of the editview tiddler (not to mention the minimal default size).

@twMat I think the canvas size should be adjustable at the beginning. I think this is also supported by what is already in the core. But have not looked at the code maybe @tobibeer knows better.

One thing that would not cost anything but that woudl make the current drawing function more useful is if one could make the editing canvas bigger in some smooth way.

Something like zooming would cross the line I guess because it requires much more code than what is already there. I think the only solution is to pick a size in the beginning before you start drawing.

[pmario]

resizing in edit mode of the canvas can be done by default atm. there are 2 size input fields.

[felixhayashi]

resizing in edit mode of the canvas can be done by default atm. there are 2 size input fields.

Thanks @pmario I didn't even notice! Very nice.

[twMat]

resizing in edit mode of the canvas can be done by default atm. there are 2 size input fields.

Yes, but this that's fiddly. Besides how many px is, say, 6cm? And if you set it to more than tiddler width, it shrinks to fit tiddler still in edit! IMO it should really be bigger. Maybe there could be a drag handle instead?

Or, remove the [show preview] button which is pretty pointless for images and instead put a [large canvas] button there that expands to some predefined value.

BTW, @Jermolene - it seems there's a minor bug; Changing the default width to 30 instead of 300 (and activating the 30 by merely clicking on the other value) makes the canvas jump to side.

[pmario]

Yes, but this that's fiddly. Besides how many px is, say, 6cm?

The UI should allow the string 6cm as an input. ... So this may be a bug. ...

Just to be sure. 6 cm will be different on every screen, that has a different resolution as yours.

And if you set it to more than tiddler width, it shrinks to fit tiddler still in edit! IMO it should really be bigger.

This is your point of view. If I need a fully fetched image editor, I use one. eg: Gimp. -> plugin

Maybe there could be a drag handle instead?

Drag & Drop isn't free. You'll need quite some js to make it happen. Until the core supports it. -> plugin

[twMat]

And if you set it to more than tiddler width, it shrinks to fit tiddler still in edit! IMO it should really be bigger.

This is your point of view. If I need a fully fetched image editor, I use one. eg: Gimp. -> plugin

Well, I'd say any implementation is a point of view also the current one. But my point is that for editing, why would you want the canvas to shrink as you enlarge it? For previewing it, sure, but not really for editing? It just makes editing harder. Or?

Maybe there could be a drag handle instead?

Drag & Drop isn't free. You'll need quite some js to make it happen. Until the core supports it. -> plugin

I was referring to the corner handle you see in e.g text-area editors. If the drawing editor doesn't have this built in (just maybe it is based on some html element that does, I don't know) then maybe one could put the drawing editor inside a simple div that has this corner resize, and set the drawing editor size itself to "maximum" but thus size-limited by the sorrounding div which has a default size but can then also be resized by the user. Maybe the current implementation is not suitable for this, I have no idea.

[pmario]

as I wrote resizing the canvas isn't free. making the canvas bigger shouldn't be a big problem. but still js code is needed. making the visible canvas smaller as the current content will need a lot more code, if you don't want to loose content.

using a wrapper and overflow:auto may help. it needs to be tested.

I still think the core should be as minimal as possible. extensions should be plugins.