Two weeks on from the Tizen Developer Conference in San Francisco, we have reached a banner day for Kitsilano Software and MonoTizen – our first full day of production. Monkey-tastic!
All of the work will be happening in the open at https://github.com/kitsilanosoftware/ if you want to follow along, or even to make contributions yourself. Pull requests are welcome 🙂
Damien Diederen will be starting work today on the process of getting the Mono Runtime to “fully supported” status from its current unknown but seemingly fairly healthy state. The rough plan for that work is shown in the Mono Runtime swim-lane of the diagram below:
My apologies for the imperfectly lined-up boxes above. They hurt my eyes too. I’ll do a better diagram later!
In around two weeks time, Dimitar Dobrev will be joining the team, starting work on the Tizen C++ API bindings. The scope and optimal ordering for that work is still to be determined, but I imagine this thread of work will be ongoing for many months.
Dimitar is one of a handful of developers in the world with experience using the superb CppSharp C++ binding tool. João Matos, who works for Xamarin, is the primary developer. Dimitar has done extensive work with CppSharp over the last year or so, including the QtSharp project, which will be a key component of the binding work within MonoTizen. I am delighted to have Dimitar joining the team!
The third thread of activity is for the MonoDevelop Tizen plugin, which will be modeled after the bit-rotted MeeGo plugin.
I anticipate that we will have enough progress to make an initial MonoTizen release this quarter (June-September), maybe even within a month or so, depending on the initial scope. The minimal viable product will, I think, be an IDE integration which allows you to build only console applications. That would require none of the Tizen C++ bindings, because you would only be able to build general C# applications using the BCL. We would just need the IDE plugin, a working Mono Runtime, and a small bit of glue for the Mono embedding within a C++ application.
After that initial release, future drops would probably be scheduled around particular subsets of the C++ APIs having been bound, and IDE wizards built around those APIs. For example, maybe Release #2 adds OSP support, Release #3 adds Qt support, etc. When I have a better idea of the scope of the API binding work, and a planned order, we’ll be in a better position to estimate time-scales on those later releases.
If we could release something at a monthly cadence, that would be ideal.
Let the fun begin!
MonoTizen 