summaryrefslogtreecommitdiff
path: root/doc/forum
diff options
context:
space:
mode:
Diffstat (limited to 'doc/forum')
-rw-r--r--doc/forum/ikiwiki__39__s_notion_of_time.mdwn35
-rw-r--r--doc/forum/managing_todo_lists.mdwn41
-rw-r--r--doc/forum/usedirs___38___indexpages_using_problem.mdwn5
3 files changed, 81 insertions, 0 deletions
diff --git a/doc/forum/ikiwiki__39__s_notion_of_time.mdwn b/doc/forum/ikiwiki__39__s_notion_of_time.mdwn
new file mode 100644
index 000000000..ee564fcc9
--- /dev/null
+++ b/doc/forum/ikiwiki__39__s_notion_of_time.mdwn
@@ -0,0 +1,35 @@
+I'm having some difficulties with ikiwiki's notion of time.
+
+For (regular) pages, the *last edited* date is the one where the file
+was indeed last modified according to the file system information.
+The *created* date (commented out in the HTML) is, at least for
+`--getctime` operation, the date, where the file was last registered
+as changed with the VCS.
+
+Now, at least with git, the thing is that when you're checking out files,
+they'll get the checkout-time's current time stamp.
+
+What I strive for is the following: *created* be the date when the file
+(under its current name) was *first* registered with the VCS (which is
+more logical in my opinion), and *last edited* be the date the file was
+last registered as changed with the VCS, which is the current
+`--getctime` *created* date.
+
+This means that I can build the HTML files from different checkouts of the
+VCS and they won't differ in the time stamps they contain in the HTML.
+
+What is the rationale for ikiwiki's current behavior with respect to these
+time stamps?
+
+--[[tschwinge]]
+
+> Presumably it's the authors of the git and mercurial backends
+> not understanding the documentation for `rcs_getctime`,
+> which states:
+>
+>>This is used to get the page creation time for a file from the RCS, by
+>>looking it up in the history.
+>
+> I've fixed both broken implementations to correctly look
+> up the first, not the last, commit. Other VCS do not seem
+> to have the problem. --[[Joey]]
diff --git a/doc/forum/managing_todo_lists.mdwn b/doc/forum/managing_todo_lists.mdwn
new file mode 100644
index 000000000..b4bbac255
--- /dev/null
+++ b/doc/forum/managing_todo_lists.mdwn
@@ -0,0 +1,41 @@
+I keep some TODO lists on ikiwiki pages. I'm half-tempted to write a plugin
+to make ticking items off and adding items easier via the web interface. I'm
+aware though that this is not really what ikiwiki is designed for. Would
+anyone else find this useful? -- [[users/jon]]
+
+----
+
+My subsequent thoughts about how to approach this are two-fold.
+
+Firstly, a filetype for todo lists, probably OPML, but I haven't looked to see
+if there is something more suitable. A plugin that converts this source into a
+traditional page output, i.e. a DOM tree of ul or ol and li elements.
+
+Secondly, some magic javascript to make editing the list via the web page
+more interactive: add items, strike items out, reorder items etc., without
+round-tripping to the cgi for each operation.
+
+Finally, a mechanism whereby the changes made to the page live can be
+committed back to the repository:
+
+ * ...perhaps the input → output conversion is reversible, and the HTML DOM
+ representing the list can be transformed back into the source and submitted
+ to the cgi like a regular edit: issues include the result of other
+ postprocessing: templates, wikilinks, etc.
+ * perhaps an embedded copy of the source is included in the output and the
+ javascript operates on that in tandem with the static copy
+ * perhaps the "output" is generated live by the JS at view time (with maybe
+ a plugin-generated rendered output for non JS environments)
+
+I envisage a button called "commit changes" appearing once some changes are
+made that submits the changes to the CGI, perhaps via a back channel. I'm not
+sure how to handle embeds or challenges from the CGI such as a login challenge
+(maybe the back channel would not be necessary in the first cut).
+
+> You might look at the [[plugins/hnb]] plugin. HNB supports checklists.
+> There's not a fancy web interface, but the hnb command-line program can
+> be used to edit them. --[[Joey]]
+
+>> thanks - I'll give it a look. I spent a few hours writing some javascript to manipulate a ul/li DOM tree in an outliner-fashion the other day. I might be able to join the puzzle pieces together sometime. [[Jon]]
+
+a solution for this could be similar to a solution for [[todo/structured page data]], as todo lists are definitely a form of structured data. (in both cases, the page's current content is rendered into a html form, whose result is then saved as the page's new contents) --[[chrysn]]
diff --git a/doc/forum/usedirs___38___indexpages_using_problem.mdwn b/doc/forum/usedirs___38___indexpages_using_problem.mdwn
index 1ca95cc88..05c85e281 100644
--- a/doc/forum/usedirs___38___indexpages_using_problem.mdwn
+++ b/doc/forum/usedirs___38___indexpages_using_problem.mdwn
@@ -10,3 +10,8 @@ But in the page [OSS.html](http://atoz.org.cn/Whatis/OSS.html) , the auto genera
to “Whatis” is /Whatis.html file , not to /Whatis/index.html. So the link to “Whatis” is fail .
Is it a bug , and how can I do for that ?
+
+> I suggest that you name your page `Whatis.mdwn`, and not
+> `Whatis/index.mdwn`. That will make ikiwiki's links work,
+> and allows you to link to the `Whatis` page by that name.
+> --[[Joey]]