Chordious and WinForm Woes

If you’ve been watching the Chordious repository on GitHub, you’ll notice that there haven’t been any commits of UI code. There’s a reason for that – it’s not going as planned.

Chordious 1.0 was built to run on Mono on Ubuntu, using Gtk# for the UI. The fact that a little elbow grease made the same binaries work on Windows and OSX was all bonus. Now, the plan for Chordious 2.0 is to be cross-platform from the beginning. Cutting ties with Mono, switching from Gtk# to good ol’ WinForms, which would run natively on Windows, and yet still function via Mono for Linux and OSX.

So for the past couple weeks, I’ve been prototyping out a base UI in WinForms, tentatively hooking up key features, and seeing how it runs on all three OSes. The results have been less than stellar.

The Issues

Here’s what’s happening:

1. WinForms looks dated

Try as I might, everything I do feels like a classic case of “putting lipstick on a pig”. On my fancy modern Windows 8.1 machine, WinForms just feels old. On Ubuntu, it’s a straight-up eye-sore. By comparison, the old Gtk# UI blends in nicely on Ubuntu, and at least looks good on Windows, if not native.

2. WinForms UI controls have some annoying limits

One of the primary functions of Chordious is to display an array of selectable chord diagrams, particularly as results in the Chord Finder. In WinForms I have one option: the ListView. The problem with the ListView is it’s meant for file explorers with icons – so the max image size is 256×256. Not that bad, but it does require me to manually resize diagrams so they don’t get all distorted. There’s also a large amount of wasted padding between the images that I can’t get rid of.

3. .NET SVG renderers aren’t as good as librsvg

Chordious 1.0 used librsvg to render the actual diagrams. Librsvg is solid library, and renders images beautifully. But for WinForms, my two real options are SVG.NET and SharpVectors. Both are relatives of the dead SVG Rendering Engine, and neither is perfect.

Of the two, SVG.NET is both the more robust and actively maintained. For Windows, it represents as fairly solid replacement for librsvg. However, on Mono, it just doesn’t want to cooperate. Text won’t render. Basic shapes, if they render at all, render as solidly filled with black every time, no matter what I do.

SharpVectors hasn’t been updated since 2011. It’s a little rougher to use code-wise, but since I’m not drawing anything too complicated with these diagrams, the images turn out okay. It works on Mono, but has some annoying quirks – like always misaligning text. The one plus is that SharpVectors has SVG to XAML support. This may make Windows Store and Phone apps much easier to design when when I start looking in that direction.

I actually coded the prototype to include both libraries, allowing the user the option to choose which renderer to use (in case new versions are released that fix the bugs) but also default to the best one for their OS. It’s a serviceable workaround at best.

4. WinForms on Mono is buggy

This one is the real kicker. The first issue was with the aforementioned ListView. Using Mono, the grid of images is fixed to a single centered column – lame. Also, selecting an image doesn’t highlight the image, but rather a underlines the spacing beneath it. Simply put, it looks awful.

The next issue I ran into was the use of the DataGridView. In WinForms, it’s a super-powerful, super-useful, way to have editable tables of data. In Chordious I used it to show tables of setting and style options for quick experimenting. Unfortunately, the Mono implementation is incomplete and buggy – I had to rewrite the code multiple times just to get the app (which worked fine on Windows) from stack-overflowing itself in Mono.

And even after I finally worked around the issue in code, I still hit a pretty nasty bug. Basically once you edited one cell in the table, if you tried to edit another, the app would crash. I understand bugs exist, I don’t have a problem with that. In fact, this particular bug even got fixed, and even though it didn’t make it into the latest Mono release, presumably will make the next one. I tried a private binary with the fix and it worked fine.

The shot over the bow however, was that this bug was reported over two years ago, and just got fixed a month ago. It’s a warning of how much the Mono team cares about WinForms support. To be fair, I don’t blame them. WinForms is old tech – even Microsoft hasn’t done anything with it in years. Mono WinForms support was there to show-off to old developers (especially corporate ones) that they can take their old WinForms apps and run them on Linux without recompiling – it’s not to encourage new developers to keep making more WinForms apps. There are better options. But in this case DataGridView and ListView are, especially in corporate applications, super important to have. The fact that they’ve been so righteously broken and ignored for so long means it’s big gamble for me to depend on them now.

5. Portable Class Libraries don’t even work with Mono

In the 2.0 kickoff post, I made a big deal about how, by using Portable Class Libraries, I was writing one single library of core code that was going to support all the various versions of Chordious apps. The problem is, PCL libraries need .NET 4.0 minimum on PC. Mono only supports .NET 3.5, and so won’t load PCL libraries. So despite all of my clever coding, I still needed a whole separate project just to compile the core code as .NET 3.5 (which did require some annoying code changes, but nothing too bad). Still, so much for one library to rule them all.

The Options

So what am I to do? I think I have three real options:

1. Keep using WinForms

Pros:

• Already started
• A non-trivial amount of work won’t have been wasted
• Only one app to create and maintain to support three OSes
• Windows users don’t have to install Mono

Cons:

• Each OS is effectively treated as a second-class citizen:
  • Windows users get an outdated, limited UI
  • Mac and Linux users get a buggy, even uglier UI
• There may be more ugly issues hiding that I’m not aware of
• SVG rendering is a definite step down for everyone

2. Switch back to using Gtk#

Pros:

• Looks pretty on every platform
• Might be able to salvage some of the UI from Chordious 1.0
• Only one app to create and maintain to support three OSes
• SVG rendering will be the best it can be

Cons:

• Some amount of starting over
• A non-trivial amount of work (on WinForms) will have been wasted
• Windows users will have to have Mono installed
• I’ll need to use two IDEs to develop Chordious:
  • Visual Studio for the Windows Store and Phone apps
  • Xamarin Studio / MonoDevelop for Windows, Linux, and OSX desktop apps

3. Use XAML for Windows and Gtk# for Linux / OSX

Pros:

• Every platform is using native UI
• Might be able to salvage some of the UI from Chordious 1.0 for Linux and OSX
• It’ll be easier on Windows to share code between a XAML-based desktop app and XAML-based Store and Phone apps
• SVG rendering will be a reasonable compromise for each OS
• Windows users don’t have to install Mono

Cons:

• Some amount of starting over
• A non-trivial amount of work (on WinForms) will have been wasted
• I’ll need to develop every bit of UI twice, once for Windows, once for Linux / OSX
• I’ll need to use two IDEs to develop Chordious:
  • Visual Studio for the Windows, Windows Store and Phone apps
  • Xamarin Studio / MonoDevelop for the Linux and OSX desktop apps

Where am I leaning?

At this point I’m mostly leaning toward option three, starting with Gtk# UI first. Sure, it’ll mean writing a lot more code, and so will take a lot longer, but I think it’ll produce better apps in the long run. By starting with the Gtk# UI first, I’ll basically be coding toward option two, since Windows users can still technically run the Gtk# UI as long as they have Mono installed.

Once that’s in a reasonable state, I’ll start on the native Windows app for people who don’t want to install Mono. Since the core of the code will still be the same, users should easily be able to switch from one to the other without losing anything.

The biggest decision, I think, it to abandon WinForms all together. If I’m already working on a Gtk# UI, there’s no reason to keep a WinForms UI. At the very least Windows users can use the better Gtk# UI until I get the XAML one ready. And a lot of the prep work for the XAML app should also be reusable toward the Store and Phone apps.

Anyway, sometimes you just need to start coding to see if your plan’ll hold water. Guess it’s time to download Xamarin Studio…

P. S. Once I start using Xamarin Studio, the option to make Android and iPhone apps also opens up. (Presuming I’m not exhausted after making so many Chordious apps and can find someone willing to pay all the licenses.)