Naracea 1.1.2: Installing .NET Framework as part of installation process

There is new version of Naracea available: version 1.1.2. What is new in this version? I replaced installer. For versions prior to 1.1.2, Naracea was distributed as MSI file, which is Microsoft Installer package, for 1.1.2 and further I’m using NSIS, which generates EXE file which installs the application.

Why did I change the installer? Well, because with NSIS I can easily bootstrap .NET Framework for computers which do not have it installed. With MSI file, you either need to have .NET 4.0 installed on your computer already, or you need to go to Microsoft download page and install it manually. It is somehow annoying, to try to install the application, then being interrupted by some messagebox which tells you that you need to do something else, before you can continue.

Therefore I decide it is time to get over this, and change the installer.

Don’t get me wrong: MSI is not that bad if you have right tools to author it. By “right tools” I mean WixSharp, which allows you to write installers in C#, which is much more convenient that using original Wix, which requires writing cryptic XML files. The problem with MSI is, that you cannot write single file installer (as far as I know), which would check whether you have .NET 4.0 installed and download it and install in case you don’t.

Thus I was looking for something to overcome this limitation, and from available options, NSIS looks the best.

Now I’ll describe shortly what I do to build this new installer.

First of all, I have file “VERSION” in my project folder, which contains current version of the application without build version. The build version (that last number which is attached to the end of the installer’s file name) is generated by the rake script when I start build process, and it consists of last two digits of the year (so for builds done in year 2012 it is 12), and from number of the day in current year (so build 121 was build on the January 1st of 2012).

Now, for NSIS install file I need this exact release version, so it can be attached to installer’s file name and to be set in Windows registry entry, which shows Naracea in “Install Programs and Features” control panel.

Following rake tasks generates “VERSION.nsh” from VERSION file with full version number and runs makensis.exe program which processes installer script and generates installer EXE file:

task :pack_release do | task|
  puts 'packing release files...'
  ver = "0"
  File.open("VERSION", "rb") do |file|
    ver = file.read
  end
  
  ver = ver + "." + get_build_version()

  File.open("VERSION.nsh", "w") do |file|
    file.write("!define VERSION \"")
    file.write(ver)
    file.write("\"")
  end
  
  system '_tools\nsis\makensis.exe naracea.nsi'
end

def get_build_version()
  return Date.today.year.to_s[2..4] + Date.today.yday.to_s
end

To run this task you need to have NSIS in folder “_tools\nsis\” (relative path from where you run the rake). When getting NSIS, download and install plugin Inetc, which is needed by installer for file download (in this case .NET Framework 4.0 installer).

Now we are ready to write the NSIS installer script, which will check whether .NET 4.0 is installed, and if it isn’t, it will download it and install (I removed mentions of Naracea from it, because some people tend to copy and paste stuff from internet without thing about it):

;--------------------------------
;Include Modern UI

	!include "MUI2.nsh"
	!include "FileFunc.nsh"
	!include "VERSION.nsh"
	!include WordFunc.nsh
	!insertmacro VersionCompare
	!include LogicLib.nsh	

;--------------------------------
;General
	
	;Name and file
	Name "<product>"
	; "_build" is folder into which your application installer will be build into
	OutFile "_build\<product>-${VERSION}.exe"

	;Request application privileges for Windows Vista/7
	RequestExecutionLevel admin

	;Additional settings
	CRCCheck on
	!define UNINST_KEY  "Software\Microsoft\Windows\CurrentVersion\Uninstall\<product>"	
	
	;Icon
	;"_icons" is folder where you have your application icon stored
	!define  MUI_ICON "_icons\icon.ico"

	;Default installation folder
	InstallDir "$PROGRAMFILES\<product>"

	;Get installation folder from registry if available
	InstallDirRegKey HKCU "Software\<product>" ""
  
	;Remove "Nullsoft Install System" text
	BrandingText " "

;--------------------------------
;Interface Settings

	!define MUI_ABORTWARNING

;--------------------------------
;Pages
	; "_texts" is folder where you license file is stored
	!insertmacro MUI_PAGE_LICENSE "_texts\License.rtf"
	!insertmacro MUI_PAGE_DIRECTORY
	!insertmacro MUI_PAGE_INSTFILES
	
	!insertmacro MUI_UNPAGE_CONFIRM
	!insertmacro MUI_UNPAGE_INSTFILES

;--------------------------------
;Languages
 
  !insertmacro MUI_LANGUAGE "English"

;--------------------------------
;Functions checking for .NET presence

Var InstallDotNET

Function .onInit
	;Here we check for Client .NET 4.0 profile. To check for Full .NET 4.0, replace "Client" with "Full"
	ReadRegDWORD $0 HKLM 'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client' Install
	${If} $0 == ''
		StrCpy $InstallDotNET "Yes"
		MessageBox MB_OK|MB_ICONINFORMATION "<product> requires that the Microsoft .NET Framework 4.0 is installed. The Microsoft .NET Framework will be downloaded and installed automatically during installation of <product>."
		Return
	${EndIf}
FunctionEnd
 
;--------------------------------
;Installer Sections

Section "<product>" SecDummy
	SetOutPath "$INSTDIR"
 
	; Get .NET if required
	${If} $InstallDotNET == "Yes"
		inetc::get /caption "Downloading Microsoft .NET Framework 4.0" /canceltext "Cancel" "<http://URL.to.NET4.0.installer.exe>" "$TEMP\dotnetfx40.exe" /end
		Pop $1
		
		${If} $1 != "OK"
			Delete "$TEMP\dotnetfx40.exe"
			Abort "Installation cancelled."
		${EndIf}
		
		ExecWait "$TEMP\dotnetfx40.exe"
		Delete "$TEMP\dotnetfx40.exe"
	${EndIf}

	;Files to be installed
	; "_build" is folder into which your application files are being built into
	File "_build\<product>\<product>.exe"

	;Create shortcuts
	SetShellVarContext all
	CreateDirectory "$SMPROGRAMS\<product>"
	CreateShortCut "$SMPROGRAMS\<product>\<product>.lnk" "$INSTDIR\<product>.exe"	
	CreateShortCut "$SMPROGRAMS\<product>\Uninstall <product>.lnk" "$INSTDIR\Uninstall.exe"

	;Store installation folder
	WriteRegStr HKCU "Software\<product>" "" $INSTDIR
	WriteRegStr SHCTX "${UNINST_KEY}" "DisplayName" "<product>"
	WriteRegStr SHCTX "${UNINST_KEY}" "Publisher" "<author>"
	WriteRegStr SHCTX "${UNINST_KEY}" "DisplayVersion" "${VERSION}"
	WriteRegStr SHCTX "${UNINST_KEY}" "DisplayIcon" "$\"$INSTDIR\<product>.exe$\",0"
	${GetSize} "$INSTDIR" "/S=0K" $0 $1 $2
	IntFmt $0 "0x%08X" $0
	WriteRegDWORD SHCTX "${UNINST_KEY}" "EstimatedSize" "$0"
	WriteRegStr SHCTX "${UNINST_KEY}" "UninstallString" "$\"$INSTDIR\Uninstall.exe$\""
	WriteRegStr SHCTX "${UNINST_KEY}" "QuietUninstallString" "$\"$INSTDIR\Uninstall.exe$\" /S"
    
	;Create uninstaller
	WriteUninstaller "$INSTDIR\Uninstall.exe"
SectionEnd

;--------------------------------
;Uninstaller Section

Section "Uninstall"
	;Remove files from installation folder
	;List all installed files here
	Delete "$INSTDIR\<product>.exe"
	Delete "$INSTDIR\Uninstall.exe"
	;Remove installation folder
	RMDir /r "$INSTDIR"

	;Remove links from startmenu
	SetShellVarContext all
	Delete "$SMPROGRAMS\<product>\Uninstall <product>.lnk"
	Delete "$SMPROGRAMS\<product>\<product>.lnk"
	RMDir /r "$SMPROGRAMS\<product>"
	
	DeleteRegKey /ifempty HKCU "Software\<product>"
	DeleteRegKey SHCTX "${UNINST_KEY}"
SectionEnd

Of course, you need to replace all occurrences of product with name of your application, and http://URL.to.NET4.0.installer.exe with URL to where the .NET 4.0 can be downloaded from.

And now you have your NSIS install script ready to build installer for your .NET application.

And don’t forget to give new Naracea a try!

Naracea 1.1

Well, it is obvious, that I’m better in developing Naracea than writing about it. Yes. There is version 1.1 available for download for some time. I was even able to release an update, and I have another one in the testing. However, I’m back now, and I’d like to go through what’s new in 1.1.

There are still three main things I’m using Naracea for, and I kind of improved things which are needed for these areas. I’m using Naracea for writing, for editing of couple of scripts, and I rely on it heavily with my note taking. Let’s go though improvements for each of these areas.

Writing with infinite undo

Since the very beginning I knew editing capabilities of the 1.0 were not sufficient. Problem was that adapting some other editing component would take some time (significant amount of time, as I found out when working on 1.1), and didn’t want to delay release. So 1.0 had to live with limited editing capabilities, and immediately after release I started to work on integration of more powerful text editing component. Finally I decided to use AvalonEdit (which is powering SharpDevelop) for 1.1.

AvalonEdit is beautiful piece of software, it is nicely designed, it has lots of features and it has permissive LGPL license. And of course: it is text editor developed for IDE. That means that while it is really great for editing code, there were some limitations when I tried to use it as a base for text editor which is meant for writing of text. So I did some adaptations and now, I believe it works really nice as the main part of the Naracea’s UI. (Naracea’s version of AvalonEdit can be downloaded from forum.)

Next feature I was really missing was simple overview of text changes. While timeline is nice, and it gives overview of the development of the text, it is not easy to explain how Naracea works and how changes are recorded when they are not visible on the first sight. Also finding the point I want to get to in document history was somehow complicated, because while the history can be searched, sometimes I do not remember what I’m exactly searching for. Therefore now there is change stream. It shows changes as they were entered, it distinguishes inserts and deletions, shows how changes are grouped and allows quick rewinding to any point in document’s history.

Minor function related to writing is possibility to show whitespaces, convert tabs to spaces automatically, and set size of tabs (if you are using indentation instead of empty lines between paragraphs).

Simple to-do lists and note taking

For note taking, there are two new important features for me. It might surprise you, but first one is the way indentation is kept when you hit enter. I build my to-do lists hierarchically, so having indentation kept when I hit enter is pretty important for me. Second feature is support for regular expressions. Searching history is hard when you do not know what are you looking for, and being able to search with regular expressions make this way easier. I know regular expressions aren’t something majority of people will use, but still — it is great to have it there.

Persistent history/undo for scripts

Honestly — Naracea is far from being best editor for writing code, and it is not my intention to turn it into one. There are lots of better tools for full time code editing. However there is this kind of exploratory coding I do from time to time, where I really appreciate I have whole history of the code available. As I already mentioned, I keep my build scripts as Naracea document. Because I’m not so proficient in Ruby and rake scripts, having the whole history and being able to develop by trial and error without fear of losing previously working code is something I really like.

That’s why I added syntax highlighting. It was cheap and easy (because AvalonEdit supports syntax highlighting out of the box — well, it is text editor for IDE), and I like to have it there for those occasions I need it.

OK, so that’s what’s new in Naracea 1.1. If you like it, please, go to the download page, and try Naracea by yourselves.

Naracea v1.1.0 RC2

Naracea v1.1 RC2 is available. In fact there was RC1 available for couple of weeks now, however just after uploading it I’ve found one really annoying error, so I didn’t advertise it at all. Now I have the problem fixed, and RC2 looks like good release candidate.

In fact, I enjoyed this final phase of release, because it meant I did some testing, and testing means writing (for my other blog written in Czech), which is something I like very much. On the other hand, the crunch period in my day job continues, and I’m usually pretty exhausted most of time, which slows the progress down a bit. And then, err… there was the Steam holiday sale, which caused I invested some time Mass Effect (which steals pretty much from every science fiction novel since sixties — namely Niven’s Ringwold, as I see it — but I like the writing quite a lot).

So, now I’ll be testing RC2 for one or two more weeks, and then the 1.1 will be officially available.

naracea 1.1.0 beta

So, where are we with naracea 1.1.0?

The most annoying known bugs? Fixed.

The failing tests? Fixed.

Help update? Finished.

Build scripts? Updated.

So it seems like the v1.1.0 beta can be released. Now, let me type “rake publish_beta” — wait for a while — OK, first beta of 1.1.0 is available now!

Yes, I know, it took way longer than I expected, but I think the wait was worth it. naracea is now much better text editor than it was in v1.0.0, and I’m finally able to switch from “use all available time for development” mode to “fix bugs and do some writing” mode. Which I was looking forward to for couple of weeks now.

You might ask why it took me so long to finish all those changes, because none of them is really that hard to implement and honestly, if I was able to work on naracea fulltime, I think 4 weeks should be more than enough time to finish everything and have the beta available. The problem is the amount of time I’m able to put in this project. Because while I’m really committed to naracea, there are some serious constrains I need to deal with.

First of all, I have a day job which I like, and in last couple of months it started to be pretty intensive, and I’m sometimes so exhausted when I come home that I’m not able to do any serious work on naracea. I really need some time to relax and recharge, I need (and want) to spend time with my family, and I still try to read a book, watch a movie or play a game for a while (which reminds me — Bastion is really awesome) to prevent turning myself into some sort of always-working-zombie.

Second problem is, that I really failed to follow the rule I set on myself when I released 1.0.0: do one thing at the time. I was so eager to implement more things, that I convinced myself that naracea is different, and that there is not a big difference between implementing a feature and delivering a feature. But of course: there are interactions between things, and adding seemingly small change here can lead to more changes somewhere else. Not necessarily because things breaks, but because it is just logical to refactor and improve that other place. And of course, the larger the feature bundle is, the more time I need to spend testing everything works correctly.

So, hopefully, I took the lesson, and next cycle (1.2.0) will be shorter and more focused.

In a mean time, as I see it now, I will spend next 4 to 6 weeks testing naracea thoroughly, and 1.1.0 release should be available sometimes late in January or in early February next year. If you would like to try naracea before the final 1.1.0 release is ready, you can try the beta yourself, because since there is little risk I’ll change something significant during beta period, I decided to make 1.1.0 beta public. So if you are not afraid of working with beta, go to beta download page and try naracea 1.1.0 yourself.

I hope you’ll like it.

+1 feature trap

There is a trap in every release. And its name is one more feature.

Well, the plan was to do one thing for the 1.1 release. One simple thing: I wanted to replace WPF TextBox with something better. After spending couple of nights on researching licenses, I decided to go with AvalonEdit from SharpDevelop, which is LGPL, which means that until I release my changed version of the AvalonEdit source codes and keep it in separate assembly I should be safe and all.

So I spent some time to replace the editor, then some more time to adapt AvalonEdit, which is, generally speaking, source code editor, to be suitable for needs of writing text editor, and then some additional time on fixing bugs.

OK, in total I’ve spent around 4 weeks working on this, and I had all the goodness which AvalonEdit brings.

But then I started thinking: while this is cool, is it enough? Shouldn’t I add something more to naracea to make it a bit more useful? And this is where I fell in the “+1 feature” trap for the first time.

I started looking for some low hanging fruit in my feature list, and I quickly convinced myself, that enabling regexes in find&replace dialog is really easy, and that it is something I can do in couple of hours. Honestly: naracea is using regex for find and replace from the beginning, the search term was just escaped right before the processing, so from user point of view it seemed like plain find&replace. And it was really easy: some 3 weeks later I got it fully implemented, and even crazy scenarios like “find two words separated by comma and swap them” were working. Great!

But then, something horrible happened. I’ve fallen in the +1 feature trap again. For some time I was suspecting that timeline is just not enough to get good overview over changes made to the document, and because I had plan for improvement ready for some time, I said to myself: hell, I can do this. I can implement change stream quickly. And I started coding little control, which shows all of the changes in more understandable way, and it proced quickly and all. But then I’ve found some performance issues, so I had to change couple of things, and then there were some new problems caused by the fact, that change stream is being built on the background, and then there were synchronization issues between the timeline and the change stream, and some other problems, which needed to be fixed.

In total, it took me 3 more weeks to get all things ready.

So now I’m happy with 1.1 content, and I have everything I want. Except for the help, which needs update. And scripts update, which will publish my version of AvalonEdit on every release, so I’m following the LGPL license. And of course there are still three tests failing in my test suite, because I changed order of things in document intialization, and until I fix these, I cannot release even beta, because to be able to release, I must have all my tests passing.

So, 1.1 release looks good. It looks good on my machine. But don’t worry: I’m working hard on fixing those remaining bugs (which are from the “annoying” but not “showstopper” category), I’m fixing failing tests, I’m writing new help sections, I’m going to update my build scripts.

And I’m not going to fall in the now dreaded +1 feature trap again. Not for 1.1 release. I’m sure about that.

naracea version 1.0 available

I feel kind of nervous, but it seems naracea v1.0 is ready. I wasn’t able to find any major bug in the application for couple of weeks now, all functionality I wanted for 1.0 is there, the registration is finally available, so there is no reason to wait:

naracea version 1.0 is available.

Actually this is kind of big deal for me. I was never releasing my own app in this way before, so I’m still learning, and well, I have sense of accomplishment, since there were times when I felt like I’m never going to get this far in the project.

Now, there is couple of things I want to talk about.

First one is registration model. Naracea is a shareware: you have 30-day evaluation period during which you should verify program does fit your particular use cases. After that you must either register or remove the application from your computer. Pretty standard stuff, I think. The registration is valid for all versions from 1.0 to 2.0, so if you like the application, but you would like to see more features there, do not worry, you can register now and then just update.

Considering this, I put lot of thinking into setting the price right. I’ve read couple of articles suggesting setting the price higher at first and then decreasing it, but I disagree with this. naracea is version 1.0 program. While I think it is solid release, it is still version 1.0 program, and we all know what that means. There are lot of features which I really want to add, but delaying release because there is one more thing I want to add would lead to nowhere. I would be never done this way, because there are always things I want to add to the program. I use the editor every day, so I know very well what other features would make it even more useful.

To get back to the point: setting price higher initially would punish early adopters for their trust in me and my product. And making somebody to pay more for less features (1.0 product vs 2.0 product) isn’t really what I see as good thing to do. I understand registering v1.0 product is act of faith, and you should be rewarded not penalized. Therefore I set the price point not to what seems economically viable for me in long term, but to what I think is right. That means that in the course of getting to the version 2.0, the registration fee will get somehow higher. So, registering right now gives you lowest registration fee and prospect for a whole bunch of new features.

This registration scheme also allows me to keep only one supported version of the application, so I can focus on further development of the program. Bug fixes will come only for the most recent release and I will be able to put as much effort as possible in new features, since there will be always only two versions I need to work on: the latest stable release for which most critical bug fixes will be delivered, and the vNext, which will contain new features. This should allow me to keep the development cycle between minor releases short (where short means something around 3 or 4 months).

This takes me to the second point I want to mention here: features which will come in future 1.x versions.

As I foresee it now, there should be one minor release for every new feature. Once feature is implemented, first beta for that release will be available with fixes coming every two or three weeks (by the way — I’m still looking for more beta users, so if you want to have access to latest features and be able to influence where the naracea goes, send me an email).

The features I plan are many. First of all, I’ll replace current text editing control with something much more powerful (work on this has already started). This should remove many limitations naracea has right now – there will be possibility for for syntax highlighting, showing whitespaces, column selections, changing tab size etc. I’m not saying I will put all these features in to UI, because I still want to keep the UI kind of minimalistic, but the possibility to have them will be there.

After this, there is support for markdown (so the text can be easily converted into formatted HTML) and spellchecker, which is essential feature for text editor targeted on writing. Then I want to focus on navigation in text and history (go to line, go to date/time in history etc.), more statistics about the text (word count, sentence count) and better branch presentation (tree of branches). After these things get a bit blurry, since I have long list of features which I haven’t prioritized yet, but which I definitively want to have.

To make long story short: I want naracea to be full featured writing text editor before the version number changes to 2.0.

So, try naracea. If you like the concept and you see potential in the application, register, and let me know what you like about it, or which features you miss. I’m listening. Really.

Persistent undo buffer for scripts and text files

Today I did what I was planning to do for some time. I added persistent undo buffer for my build scripts.

This is second side effect of naracea usage I didn’t expected when I started the development. When I moved my dev notes to naracea, I was kind of afraid of data loss. The file format was still not fixed and there were some bugs in file saving at that time. While I keep my documents in version control system (as everybody should), I was thinking I should have a backup plan for the case when something goes really wrong and document gets corrupted while being saved. So I added two phase save (first rename the existing document, then save the new version and only when the save is successful remove the previous file) and as a last resort I implemented automatic export of the document’s content to the text file.

I never needed the feature, since I never experienced the problem so bad that it would corrupt the document file, but it was there, and I was thinking how it can be useful. And then I realized that adding possibility to set the autoexport filename would allow me to use naracea as an undo buffer for normal text files.

Here is how it works: in my project folder I created subfolder named “_undo”. I created new naracea document called “scripts”. In the document I renamed the branch to “rakefile”, put content of my rake script into it and set its autoexport filename to “..\rakefile.rb”. Now, when I want to edit my rakefile, I open “scripts.ncd” naracea document and when it is saved, the rakefile branch is automatically exported to the actual “rakefile.rb” file in document’s parent folder.

Sounds complicated, but it really isn’t (see forum post which describes it in more detail).

So now, if I edit my rakefile in naracea, I have all changes made to the script persisted, and I can move back and forth in the script’s history without being scared that I won’t be able to undo changes after I close the text editor (which is exactly what happens when I use other text editors).

Sure, naracea is not programmer’s text editor, and it doesn’t support syntax highlighting etc., but still: the feature seems neat to me.

No settings

If you’ve tried naracea already, you probably noticed there is no settings dialog. This is intentional — since the very beginning I wanted naracea to be settings-dialog-free. Reason for this is the fact, that I thing that settings dialogs are evil.

Let’s say you install an application. What is the first thing you are going to do? If you are like me, you will find the settings dialog, and then waste some time by changing what is in there. Then you get used to your specific settings and when you need to move to other computer (let’s suppose the application is available there), you will feel awkward until you waste the change-stuff-in-settings-dialog time again.

And then there is the time you waste by looking into settings dialog to figure out whether there is better way to set up the application. And honestly, there is very little value in all that time invested in changing settings. You would be able to use the application pretty much the same way with reasonable default settings.

Don’t get me wrong: I’m not saying there should be no settings in application at all. There are some cases when allowing user to change things is pretty much inevitable. For text editor it would be crazy not allowing to set the font size. I’m not so sure about the font face, but that is still OK for me. But building extensive settings dialog, where you can change every little aspect of the application behavior seems, well, unreasonable to me.

In naracea, the closest I got to the usual settings dialog was autosave. When I started implementing it, I felt like I really need to create the settings dialog. But then I was thinking: when I want to enable autosave, what do I want to really achieve? The answer is: reduce the amount of wasted work when something wrong happens and application crashes, or power goes off. Do I really need to set the autosave period? I don’t think so. What I need is reasonable default autosave period, and ability to turn it off in some special cases. And what amount of work I’m willing to sacrifice? Right now I think it is 3 minutes. Therefore by default all new documents in naracea are created with autosave turned on, and the time interval between saves is 3 minutes. It is possible to turn the autosave off, but it is based on document, not application global settings, because I believe there are documents for which autosave is good and documents for which it is undesirable. Having global setting would break this, and it would enforce the autosave on documents for which I really don’t want it, or disable it for document for which I really want the feature.

So in naracea there is document properties dialog with single check box which allows turning autosave on or off.

And I took similar approach to all other things which are configurable in naracea: set reasonable default value, allow user to change some of the things, but remember, that while some settings are global, more of them is related to the document, or event branch. (In fact, there are only five global settings in naracea: font face, font size, background and text color and width of the editing area when application is maximized.) And most importantly: prevent settings dialog, which would take forever to go through.

Because at the end, naracea is text editor, and what people should be doing with it is editing text, not settings.

Keeping to-do list and notes as a text

Honestly, I’ve never believed in stories about somebody building A just to suddenly find he’s built B.

That would be like – I don’t know – me saying I’ve started building text editor fitting my writing habits so I can write that novel I have in my head, and in the middle of the process realizing that I’ve created nice tool for keeping to-do lists and notes.

Well.

You know.

That’s exactly what happened.

It all started when I moved my dev notes from OneNote to naracea. Once naracea started to be really usable, I felt strong obligation to use it on day-to-day basis. Because developing an application in my spare time, took all my spare time, I wasn’t (and I’m still not) able to do any serious writing. So I moved all the notes I kept in OneNote to naracea because it was obvious thing to do and in fact those dev notes are still one of the few documents I work with on almost every day.

Don’t get me wrong – OneNote is great application. I used it quite extensively, but there was one thing I really miss – history tracking. Keeping track of the history is crucial for me, because while I work on naracea regularly, I have only limited amount of time every week I’m able to dedicate to the development. Therefore I need to keep track of all decisions I’ve made, all bugs I resolved, and all features I want to implement, preferably in one application, in one document.

I’ve tried couple of to-do list applications, but the problem with all of them is, that either there is just too many things to change in the settings (which I always end up to do — turning things on and off, changing columns, rearranging tasks etc.), or their functions are not sufficient. And after some time every to-do list I’ve tried got noisy, and I needed to switch between different modes and views so I see what needs to be done and what is finished already.

After a short time, I ended up keeping my development to-do list as a bullet point list in OneNote, and once the task was done, I moved it to the bottom of the notepad and changed its formatting to stroke. This isn’t the nicest solution, but it seemed to work.

However, once I moved those notes to naracea, things get so much easier. I add everything to one long to-do list and I mark each task with simple marker (it is [bug] for bugs, [feature] for features). Once the task is finished, I write short note (with characters => in front of it) and then I just delete the whole task.

This keeps my to-do list as short as possible — there are only tasks I’m working on or those which are still in queue, but the information about finished tasks is not lost. I can just open the find dialog, search the history of the document for occurrences of either [bug] or [feature] to get the whole list almost instantly. Because the find dialog shows text around the matched string, I can navigate through find results quickly and find what I’m looking for.

When I need to check some facts or decisions I’ve made couple of weeks ago, I just search for keywords (let’s say when I see some chance to simplifying the code which is saving all files, I can search for “save all”), and I get the information why something is the way it is with very small effort.

Second thing which makes note taking in naracea extremely simple are branches. Originally, branches were meant to keep different versions of the document, allowing writing parallel versions or alternative endings or making reviews and editing easier. While branching can still be used for all of this, now I use then as a way to keep things related to one project in single file. Instead of using branches for real branching, I use it as a way to keep several notepads in single document.

In my dev notes I have three branches: one for general to-do and bugs, one for something I call “knowledge base” (I keep my design decisions there) and one for feature ideas. With these I have all things related to naracea development in one place, but somehow logically structured and with full history. Designing a feature is iterative process, so I first write everything down into couple of paragraphs, then I refine it and finally I clean up stuff which is not useful. But it is still there, so when I need to check why I rejected possible solution, I can get back and see why I rejected it.

I use this feature so much (for other things and projects I need to track), that I added button for creating new empty branch to the ribbon.

So while originally I started naracea as a text editor for writers, it seems that the set of features I decided to implement makes it really nice program for people outside of the community I originally meant it for.

Well, sometimes strange things happen.

(Suggestions for keeping textual to-do lists in naracea are also in this forum post.)

Release candidate for v1.0.0 almost ready

This is where we are with v1.0.0 release after recent bug hunt:

I’m quite sure there will be some more errors found as public RC will be released once I finish help, but I’m quite optimistic about finishing v1.0.0 in August, and releasing naracea in early September.

Good thing is that my original estimate of amount of work and time needed to productize the naracea was pretty accurate. This is one of the scary things about software development: polishing the product to make it ready for real world takes almost as much time as writing the code. It almost seems that program is 90% done for 90% of the time.

Well, hopefully there won’t be any major roadblocks and the work will proceed as smoothly as it did so far!