I had a long-standing bug on my list, which I've been putting off for a while, to have the installer download component pre-requisites automatically, instead of just dropping the user to a download page. I was finally spurred into action by my girlfriend, who told me, "I was going to try FeedGhost, but the installer told me I need to download something, and I couldn't be bothered".

She's quite right of course, she shouldn't have to bother. It's coded now (but not yet in the build); all a user has to do is click 'next' a few times and FeedGhost will run, although they may have to wait ten minutes or so for the .NET framework to download.

The price of that ease-of-use for our users is a right royal pain in the arse for me though; why are installers so difficult to write? Why does Windows Installer just silently fail if I get something wrong? Why does Microsoft do next to nothing to help us actually deploy .NET? The one bright light in this area is WiX, which has quirks, admittedly, but is free, feels like it was written by a competent coder, and has a reasonable community.

Still, I had to write a little MFC bootstrapper to download the pre-requisites. How people managed to write entire MFC applications I'll never know; it's like they read the OO book but didn't understand it:

theApp.m_pszAppName = _tcsdup(_T("FeedGhost Setup"));

• Why isn't this member variable private?
• Why am I dealing with char *s when there's a CString class?
• Why are ownership semantics so screwed up I have to remember to duplicate the argument?
• Why couldn't it have just been: void CWinApp::SetAppName( const CString & ) ?

Hey ho. The pain's over for the time being.

In response to a few suggestions for fairly major application changes to the FeedGhost application, here's where I see it going as a product. These are of course my initial ideas; what we actually do in the future is still up for grabs based on what feedback we get.

I see the current FeedGhost Windows application as just one part of the overall FeedGhost product. Remember that what you get for your $20 p/a is a subscription to all synchronized parts of FeedGhost. These parts would be:

• The FeedGhost Windows application

This is the primary management application for your feeds. It will contain all functionality but not necessarily the simplest reading experience.

• FeedGhost web application

Available for use when the Windows application cannot be used, this will allow reading and simple management of subscriptions via a browser.

• A simpler reader and notification application

This will be a smaller, simpler application that sits in the system tray and displays headlines. It even could be a sidebar-style application, or a widget. This might be tied to the main Windows application, with a "switch" button rather like Media Player.

• FeedGhost mobile application

We'd like to provide a simplified mobile version of FeedGhost for your PDA or smartphone. We'll need to provide an advance download facility to grab extended posts and podcasts before you leave internet connectivity.

All these parts will work together, so that (for example) if you subscribe to a new feed in one, all the others will pick that change up.

We've got a nice animated GIF for our splash screen now, but the animation ran a little jerky as the rest of the application started up and messages didn't pump smoothly. I've been so used to a single-threaded model for WinForms that I didn't even realise you could run multiple message pumps on different threads, until Lee pointed that out to me.

Here's the technique: as the application starts, start a new thread running the splash form:

static void Main( string[] args )
{
  ThreadPool.QueueUserWorkItem( SplashLoop );

  Run();
}

We're going to want to close the splash screen, so we need to (a) store a reference, and (b) we need an event to wait for the form to actually be created. The splash screen has its own message pump in this thread.

private static SplashForm _splashForm;
private static ManualResetEvent _splashCreated = new ManualResetEvent( false );

private static void SplashLoop( object obj )
{
  _splashForm = new SplashForm();
  _splashForm.Show();

  _splashCreated.Set();

  Application.Run( _splashForm );
}

The main application startup can now continue. Once everything is setup, we wait for the splash form to be created, and then make a cross-thread call to close it.

private static void Run()
{
  // Do your main application startup here, and probably display a main window.
  // ...

  _splashCreated.WaitOne();
  _splashForm.Invoke( new MethodInvoker( _splashForm.Close ) );

  Application.Run();
}

Of course this is a simplified version of what goes on in FeedGhost; the new splash screen has a minimum display time, and fades out, so we catch the 'closing' event and cancel it, so that the splash form can close itself as it wants to.

Combined with a per-pixel-alpha layered window technique we now have a nice smooth loading page. Is it important? For one hour's work, I think so: it's one of those 'first impressions' (after the website and installer) that can colour a user's perception of the product.

Up until now FeedGhost has suffered visually with my placeholder icons. We've now got the first version of the toolbar and application icons from our graphic designer, and the overall look is starting to come together.

I'm beginning to think that we ought to extend the theming system to the article viewer style. The green looks fine on the jet black, but looks rather out of place when I use the Windows blue version.

And it really is pointless, as I currently have a readership of exactly one. However, the journey from Z-list to A-list has to begin at Z.

My name's Stu Smith and I co-founded BinaryComponents Ltd a couple of months ago. Currently we only have one product in development FeedGhost, but in time we hope to have other applications and components available.

Prior to BinaryComponents, I spent about half my life in academia (here and here), and about half in industry (here and here).

I'm resposible for the main FeedGhost application, especially the user interface. Any questions or comments feel free to post a comment or email me; feed parsing and website comments should probably go to Lee.