MediaWiki is a fantastic system, but it requires a LAMP Stack to really work, and the fact that all data is in a database doesn't make it very Source Control friendly. So I really wanted to solve two different problems: I wanted all the data in the file system, so that it can be checked into source control and easily be shared by other people. So no database server. But to share it with other people, they need to be easily able to read the files. I did not want an application that digs deep into the system. Ideally, I do not want to require installation at all and leave no marks in the system.

So the original SWiki solved problem 1 by using a SQLite Database. There is nothing wrong with using a database as long as it's 100% filesystem based. My attempt at Problem 2 was to host the Internet Explorer COM Object Microsoft exposes and feed it HTML. That way, I don't even need a web server. But that attempt ultimately proved a failure. I could not do much of the rich formatting I wanted, even embedding images was impossible. At some point I questioned whether my use of HTML was correct, or if I shouldn't just use RTF and embed stuff using OLE.

But my problem wasn't the Markup part. I like the WikiPlex markup, and the library is clean and extensible. I really didn't want to try using OLE/RTF as these technologies are not meant for human consumption. Also, I want to keep the ability to export the Wiki to HTML so that it can be hosted on a real web server if desired (e.g., the documentation section of a project).

So really, I need a Web Server. But I don't need a particularly "good" one, especially because I do not want a large "footprint" in the network. Really, running a web server is a great way to trigger all sorts of security software across the entire company. But without a webserver, SWiki is simply not good. So I've started looking at the Cassini Web Server, which is conveniently open source under Ms-PL. This is a great server for many reasons. One, it's 100% managed code, so it can be completely embedded in my app. But more importantly, it can be configured to only ever listen on local loopback, that is 127.0.0.1 for IPv4 or ::1 for IPv6. This may still trigger some security software, but it seals off the application from the network, so no interruption should be caused in theory.

Overall, this is a good compromise. I gain the ability to turn SWiki into a full-blown ASP.net application by simply bundling it with a lightweight web server and control utility, all while still being able to keep the data in a single file. So this is what I will do now. I haven't decided if I keep SQLite as database or use SQL Compact due to it's much better integration and if I'm able to offer an upgrade for databases between "SWiki old" and "SWiki new". I haven't even decided if I keep the name or change it, although the existence of another wiki by that name makes me want to change it.

The only thing I really have decided on is that it will support images and that it will still use WikiPlex as it's parser, all while still requiring .net 3.5 and all while - at it's core - still being a simple, standalone desktop wiki, although a little bit less simple than originally envisioned.

A few weeks ago I started a WinForms application, which is my first foray into a real WinForms application (I have written some before, but those were very simple tools, not full-blown applications.) I have to admit that not much planning went into SWiki. I kinda knew what I wanted, but at the same time I didn't because I had not used it yet. SWiki 0.8 was finished in about 6 hours and I started using it to create some real documentation. And by using it, I saw what did not work and what additional features are needed, which I put in a Road Map and implemented in the order I deemed appropriate. I've released 4 updated versions and I am about to release 0.13, and it just struck me.

The thing became a big ball of mud. Really, look at the code for the Main Form. I have the User Interface extremely tightly coupled to the database. In fact, if I want to programatically select another wiki page to display, I call the SelectPageInTree() function, which Selects a Page in the TreeView. This triggers the AfterSelect Event of the TreeView, which will change the Page. This is completely stupid. Even worse: I am currently trying to fix the Re-Parenting feature so that you can parent pages to the root page again. Unfortunately, there is no good way to do it without either making the UI illogical or having tons of side effects and more global variables.

Now, this does not mean that it's beyond repair. SWiki is a rather small project and I can easily fix that with a day or two of work. But really, I have to go back to redesign and rebuild the UI from the ground up, now that I know which features I need. That's not a complete rewrite, but I think Jeff Atwood is right when he said "Prepare to write your application three times". SWiki 0.8 was already the second version (the first one was more a proof-of-concept/experiment, but still), so I guess that is my third time now

As said, in a web application I found it rather natural to have Logic and UI separated, mainly because of the stateless nature and because I "rebuild" the UI on every request anyway. In a WinForms application, that is not the case, and I think it's a lot easier to accidentially make your user interface part of the core application instead of just using it for Input/Output of data. I'm going to read about the MVP and MVVM patterns a bit I guess. MVVM is what is commonly used in ASP.net MVC and WPF/Silverlight applications, so I do not know if it's applicable to WinForms.

So yeah, still plenty of work to do until SWiki 1.0 (I am also thinking of renaming it because Swiki is already the name of another Wiki), but overall I am quite happy with how the current 0.13 alpha works, and at the end of the day, that's what matters more than perfect code. I'm currently holding off the 0.13 release and merging it with the 0.14 version which had the UI Overhaul planned anyway.

Also, because SWiki is still under heavy development, I would have to chase translations first before I can release. So for the time being, I moved it to a later version in the road map.

Instead, I have added a feature to 0.12 that I really needed now that I'm actually using SWiki to create some documents, and that is re-parenting of pages. This allows you to move pages within the tree to other pages. You can not turn a page into a root page at the moment (that was an oversight, to be fixed in 0.13).

Additionally, the Page view now allows copying text through CTRL-C or Right Click => Copy, and in the navigation tree on the left, the Main Page will always be the first page. You can download SWiki 0.12 on the CodePlex Download Page.

Export Wiki into HTML Files
Using the now-functional export button in the button bar, you can export your wiki to HTML files. This will generate one file per page, complete with navigation.

Diff between Revisions
There is now a new "Diff" Tab on the main screen. This allows you to pick any two revisions of a page and quickly compare them.

Other changes
Apart from these two big points, there are some other changes. In the doc folder, you will find a more elaborate user manual in .swk format. The navigation menu on the left has a context menu now to add new pages. The Syntax Help window should no longer open outside of the screen if the SWiki window is too close to the edge.

Download SWiki for free on http://swiki.codeplex.com/

You can give a Title to each database now. To do that, simply click on the settings button (the cogwheel in the lower left button bar) and type in a title. The new Title will be reflected on the title bar as well, which is useful if you have multiple SWiki instances open.

There is a new Macro that you can use in your wiki pages to change the color of text: [color:ff0000|Your Text] will display the text in red. You can of course combine this with other format specifiers, for example *[color:0000ff|Your Text]* for bold blue text.

Also, there are a few UI Bug Fixes. The tab order should make sense in every window, and you can actually press return in the "New Page" dialog. Users of Version 0.9 will have to convert their database into the new format, as 0.10 changed the schema. To do that, there is an Upgrade tool included.

Download it for free from CodePlex now

    this.browser.ObjectForScripting = this;

The next step was to create a function in my Form that can be called:

    public void BrowserInternalLink(int targetPageId)
    {
        ChangePage(targetPageId,null);
    }

I've created some code for testing that illustrates how to call it:

    sb.Append("<a href=\"javascript:window.external.BrowserInternalLink(1)\">Test</a>");

So this would call my BrowserInternalLink Function with the Parameter 1. Pretty neat, but still useless as it's hardcoded

The next step is to add support to the [wiki:PageId|Description] syntax to WikiPlex. Here, two articles are really important: Extending WikiPlex with Custom Macros and Extending WikiPlex with Custom Renderers.

If you want to add your own Tags to WikiPlex, you may need both usually. A Macro is some RegEx that tells WikiPlex to search for certain tokens and how to interpret them (For example, you can tell WikiPlex that you want to discard a part of the token, but pass other parts into a renderer). A renderer takes the Input and outputs some HTML. As said, your Macro is split into multiple parts (depending on your RegEx) and in theory you can pass every part into a different Renderer.

Have a look at WikiPlexExtensions.cs in the SWiki Source Code to see my implementation. The main downside of this whole approach is that it requires FullTrust, but so far I don't know a better alternative. There is a GDI+ HtmlRenderer on CodeProject, but that sadly renders out images, which means: No links, no Copy/Paste, just look but don't touch. The Mono Project seems to have a very interesting approach, but "Replacing the Browser" is currently low priority, especially since Windows 7 E will not happen (By the Way: SWiki is of course compatible with Windows 7)

I really like WikiPlex so far, as it is a very clean and extensible Wiki Parser, and I think I will have a lot of fun with it

SWiki 0.9 also allows you to print out pages now, simply click the new Printer-Button on the lower left toolbar.

Grab it from CodePlex now

So ideally I want something like a Wiki: Rudimentary but solid and easy formatting, no black auto-correction magic that gets in my way, and a nice document outline. The problem with MediaWiki is that it requires a webserver and MySQL database, which is a bit heavyweight. I looked at alternatives and found ScrewTurn Wiki Desktop Edition which sadly requires installation, and TiddlyWiki which looks great at first, but somehow I've lost my data twice, possibly by not saving even though AutoSave is ticked. I don't know, maybe I am just not smart enough to use it, but I did not like it.

At the end, I decided to roll my own thing, called SWiki. SWiki is a simple, standalone wiki. At it's core, it's a SQLite database, using WikiPlex as it's WikiParser and the C# WebBrowser Control as an integrated Browser. No installation required, only .net Framework 3.5 SP1 needs to be installed. It's Open Source and Version 0.8 can be downloaded on CodePlex.

It may not be the most impressive software ever written, but hey, I've written this for me after all

SWiki 0.8