yes, we don't hook anything. i've not tried this, but you should be able to hook on to the paste event for that div (the div is really your markup, we don't do any magic shadow iframing)
this does exactly that, sets a div to contenteditable=true, but also binds hotkeys for common operations, extends with toolbar support, provides filereader for drag&drop.
we don't create a toolbar. It's up to you. so if you don't put buttons for that, they won't be able to do it. hotkeys on the keyboard are also configurable, you can just bind certain items so users won't be able to execute the other commands unless they open a javascript console and call doc.executeCommand manually (but then again, that's difficult to prevent for other editors)
could you check what content type the filereader reports when you upload from safari? I've just tried again with safari on OSX and it seems to work. perhaps I should detect the extension, not just content type...
Firefox on OSX works fine... so it's a combination. I don't have a linux box handy to test, but it would be nice if you could see if keydown is the problem, and if so we'll change it.
I think that's a bit harsh. First of all, we got it to the point where it's useful for us and shared it. If it's close to what would be useful to you but not 100% there, fork, extend and submit a pull request, that is how opensource works.
I've not tested it in IE because IE is simply not on the critical path for us. That doesn't mean it does not work in IE, I've just not tested it.
After about three months, we looked at usage patterns for MindMup and decided to drop official IE support, as it represents less than 2% of our usage and most people have an alternate browser installed as well.
If IE is on the critical path for you, you could contribute by testing and submitting fixes.
You can make it create paragraphs and headings by adding a button for the formatBlock command to your toolbar. Google for execCommand, all those things are supported out of the box.
no, this is an input field with chrome speech enabled (<input type="text" x-webkit-speech>). The microphone icon you see is the right part of that field, and the text is transparent. We've done it like that because at the moment only input fields support speech input in chrome, and we couldn't find a way to activate programatically.
There is no onclick event on that part, it's just part of the text field.
Thanks for reporting this. I didn't test under Linux as I don't have a linux box handy. We bind keyboard events to jquery keydown. Is it better to bind to something else for FF/Linux?
can you give me a bit more info on "can't"? Did you try drag & drop or toolbar? what file type have you tried? We have a filter on content type in the editor, so only things read with content type image/* are inserted.
Perhaps this is too strict?
re "code" button, this would be trivial to implement but doesn't really belong in the widget. Just get the html out using jquery (it's your element) and show that instead of the element by passing through a formatter (or just jquery.text())
I've not tried this, but I believe this would come down to creating a button that calls insertHtml with the basic table strucure, and calling enableInlineTableEditing before that.
some cleanup might be good, eg when you select everything using cmd+a, then delete, some browser leave a <br/> in the content.
I didn't like forced sanitization in wysihtml5, so we added an optional method .cleanHtml - you can just use the normal jquery html method to get the non sanitized contents, or call cleanHtml() to get trailing empty divs, <br/> and whitespace removed