responses
[ikiwiki.git] / doc / todo / wikiwyg / discussion.mdwn
index e5abfa9d489c7363773c761206c307c4301f4874..9702092cf659c49990adfffc80d5a7a245355185 100644 (file)
@@ -23,7 +23,7 @@ A few observations, in approximate order of priority:
   wikiwyg.tmpl out to a separate .js file to save space in the rendered
   pages.
  * Done.
-* Both this plugin and the [[Gallery_Plugin_for_Ikiwiki]] are turning out
+* 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
@@ -52,4 +52,96 @@ A few observations, in approximate order of priority:
 
 Oh, by the way, let me know if I forgot to tarball anything. --[[TaylorKillian]] 
 
-[Javascript Compression]: http://javascriptcompressor.com/
\ No newline at end of file
+[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..
+* 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()`.
+
+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?
+* 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]]
+
+[Revision 3840]: http://ikiwiki.info/cgi-bin/viewvc.cgi?view=rev&root=ikiwiki&revision=3840