]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/wikiwyg/discussion.mdwn
Merge commit 'upstream/master'
[git.ikiwiki.info.git] / doc / todo / wikiwyg / discussion.mdwn
index e14fbf498e1527ebf8f561c0908e278e293273a9..304b3962095361a549a68f8c3ef199f69490146e 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.
   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
   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
@@ -50,4 +50,129 @@ A few observations, in approximate order of priority:
 
 --[[Joey]]
 
 
 --[[Joey]]
 
-[Javascript Compression]: http://javascriptcompressor.com/
\ No newline at end of file
+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]]