diff options
Diffstat (limited to 'doc/todo/wikiwyg/discussion.mdwn')
| -rw-r--r-- | doc/todo/wikiwyg/discussion.mdwn | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/doc/todo/wikiwyg/discussion.mdwn b/doc/todo/wikiwyg/discussion.mdwn new file mode 100644 index 000000000..11c96a8b5 --- /dev/null +++ b/doc/todo/wikiwyg/discussion.mdwn @@ -0,0 +1,181 @@ +Very nice! There are some rough spots yes, but this looks exactly as I'd +hoped it would, and seems close to being ready for merging. + +A few observations, in approximate order of priority: + +* What's the copyright and license of showdown? Please include that from + the original zip file. + * Done. Check licences folder +* What happens if there are concurrent edits? The CGI.pm modification to + save an edited wikiwyg part doesn't seem to check if the source file has + changed in the meantime, so if the part has moved around, it might + replace the wrong part on saving. I've not tested this. + * When you click the edit button, the exact same protocol is used for saving. + However when you double click to edit, this still is possibly an issue. +* The stuff you have in destdir now really belongs in basewiki so it's + copied over to any destdir. + * Done. +* Personally, I'm not sure if I need double-click to edit a section in my + wiki, but I'd love it if the edit form in the cgi could use wikiwyg. Seems + like both of these could be independent options. Doable, I'm sure? + * Done. +* It would be good to move as much as possible of the inlined javascript in + wikiwyg.tmpl out to a separate .js file to save space in the rendered + pages. + * Done. +* Both this plugin and the [[Gallery]] are turning out + to need to add a bunch of pages to the basewiki. I wonder what would be a + good way to do this, without bloating the basewiki when the plugins arn't + used. Perhaps the underlaydir concept needs to be expanded so it's a set + of directories, which plugins can add to. Perhaps you should work with + arpitjain on this so both plugins can benefit. (The smiley plugin would + also benefit from this..) + * Done. All plugin files are now stored in a tarball. IkiWiki checks for + <plugin name>.tar.gz in the basedir and if the plugin is being used, then + it extracts the files to destdir. Currently IkiWiki does not render these + files though (my plugin doesn't need them to be rendered). However it wouldn't + be too hard to modify it to render them. +* Is there any way of only loading enough of wikiwyg by default to catch + the section double-clicks, and have it load the rest on the fly? I'm + thinking about initial page load time when visiting a wikiwyg-using wiki + for the first time. I count 230k or so of data that a browser downloads + in that case.. + * Done-ish. I fixed it so that all of the javascript files(except for the main two) + are loaded after the content is loaded. It is possible to make is so that + the files are only loaded when you double click, however that is *a lot* + more work, plus it will slow the load time for wikiwyg. But if you would + prefer that the files only load after double clicking, I can do that. Also, + I'm working on reducing the file sizes via [Javascript Compression][]. Theoretically, + I can get the size down to about 70kb, I'm working out the kinks now. + +--[[Joey]] + +Oh, by the way, let me know if I forgot to tarball anything. --[[TaylorKillian]] + +[Javascript Compression]: http://javascriptcompressor.com/ + +--- + +Some more comments, on version 1.6. You seem to be making nice progress. + +changes.diff: + +* I don't really like the tarball approach. Doesn't feel like the right + approach somehow. A list of underlay directories feels to me like a + better approach. One reason is that it's more general than a tarball tied + to a given plugin. A list of underlay directories could also be used to + prefer a translated underlay, and use the english version of untranslated + pages, for example. + * I don't quite get what you want to do with the underlay directory, it sounds like + you have something pretty specific in mind. I can talk to you about that more + on IRC later(assuming my internet is working right). + * Basically the idea is to change `$config{underlaydir}` to an array.. + Ok, take a look at the new `add_underlay()` function. You can now just + `add_underlay("wikiwyg")` and it'll look in + /usr/share/ikiwiki/wikiwyg/ for the files. +* When is the WIKIWYG variable in misc.tmpl used? + * The WIKIWYG variable in misc.tmpl is used for the edit page. I believe that is what + you wanted me to do (Check Revision 3840). + * Ah, right. +* Could you move the code that handles saving a page of the page into the + plugin? I just added an editcontent hook, which should allow you to do + that. + * Alright, np. +* Your patch exports run_hooks, but I don't see the plugin using that. + * Yeah, that was from an earlier revision of my plugin, I just forgot to remove that. +* I don't know about exporting pagetitle. So far, only the inline plugin + needs to use that function, I generally only export things after it's + clear a lot of plugins will need them. + * Just looked through the inline plugin. So if I want to use pagetitle in my code, + I have to use the IkiWiki package instead of IkiWiki::Plugin::Wikiwyg? Or would a + better approach be to just copy that function into the Wikiwyg plugin? + * You can just call `IkiWiki::pagetitle()`. + > Note: pagetitle is now exported. + +wikiwyg.tar.gz + +* Would it be possible to provide a diff between wikiwyg upstream and any + modifications you made to its files? I'm not sure which version you used, + so I'm seeing changes in diffing that I'm unsure if you made.. + * <http://ikiwiki.xbaud.com/JavaScript_Diffs.tar.gz>, also emailed them to you + in case my internet goes down. + * Could you redo that with diff -u plz? + * Link is updated +* If the files aren't modified, would it be better for users to get them + from the wikiwgy upstream, instead of including them in the plugin? (If so, + they'd go in their own Debian package..) + * The files *are* modified, but I doubt it will make a difference. There have + been no updates to Wikiwyg since 5/30/07 so I'm pretty sure it's unmaintained + now. Showdown is the same case, they haven't changed anything since SoC began. + I could separate them diff's though if you feel it is worth it. + * Well, from a packaging perspective, the question is whether some + other package might want to use the wikiwyg/showdown javascript + files. And whether your mods might break that. If the answers to + these questions are yes and no, then it would make sense to package + them as standalone packages rather than embedding them in ikiwiki. + +misc: + +* What are your thoughts on handling plugins? Just make preview do a + server-side callback? + * That is an option, however I was trying to avoid that due to bandwidth, cpu time + concerns (Two reasons I really like IkiWiki). I was planning on just manually + implementing some of the easier ones (such as img), however I'm still trying to + think of a way for the more complex ones. + * It just seems like it would never be able to support everything, + and would mean reimplementing stuff in javscript and would constantly + need to be kept up to date. Ikiwiki's preview is actually pretty + fast, the only real overhead being the cgi call. +* How do I configure it to only support whole-page editing with wikiwyg and + not insert the javascript into html pages? + * There currently is no option to do that, however it is a 2 line change that I'll work + on after I finish typing this. +* When editing a whole page with wikiwyg, I think it would be good to keep + the save, preview, cancel buttons at the bottom like they are in a + regular page edit. Also the comments box. Kind of a least suprise thing, so that enabling + wikiwyg for whole-page editing basically just changes how the edit box + behaves and keeps the rest of the behavior the same. And I think the preview + button should show a preview rendered server-side, like with a regular edit, + since such a preview is able to support all plugins. + * That's probably a good idea ;) + +Everything else looks fine and ready for merging. If, that is, you think +I should include the plugin with all of its java code in ikiwiki. Thoughts? + +--[[Joey]] + +I'll start working on the changes... Let me know if you find anything else +that needs to be changed. I'd be honored to have my code merged with IkiWiki :) + +--[[TaylorKillian]] + +I wonder if you've had a chance to make any of the remaining changes above? +Even just some of the smaller changes would be much easier for you to +do than for me, and it would be nice to get them sorted out before I +merge it into ikiwiki. --[[Joey] + +None of the links for the WYSIWYG editor work anymore. Does anyone have an up to date link? +Thanks, [[Greg]] + +> There's a branch in [[git]] for the wikiwyg stuff, which includes +> the latest version I sucked in from TaylorKillian's svn repository before +> it went offline. Disapponted that nothing seems to be moving here. +> --[[Joey]] + +>> How far from ready did this seem to be at that point? I find it a bit unclear +>> in the above discussion what was completed and what remained. Also, to recover the +>> wikiwyg-specific stuff from git, it looks like I'd need to ask git for +>> a diff between the wikiwyg branch and its branch point; is there a nice way to do +>> that with gitweb, or would I need to install a full-fledged git client? --Chapman Flack + +>>> I think that the largest missing thing was support for using ikiwiki +>>> to render page previews. +>>> +>>> Erm.. I seem to have screwed up the creation or pushing out of the +>>> wikiwyg branch. It doesn't seem to have any of the wikiwyg changes in +>>> it, and at this point, I don't know where to find them anymore! Damn, +>>> damn, damn. I suspect I did that right when I was learning git, and +>>> screwed up pushing the branch. :-( --[[Joey]] +>>>> Seems the new place is now at Github: <https://github.com/audreyt/wikiwyg-js> +>>>> FYI +>>>> --[[users/Olea]] |