My recent blog post about the WPF adoption caused a couple a few people to ask about the future of Krypton. In particular they wanted to know if I would switch to creating WPF components or stick exclusively with WinForms. Here I hope to clarify my current roadmap. Krypton Roadmap The immediate future for the Krypton Toolkit [...]

My recent blog post about the WPF adoption caused a couple a few people to ask about the future of Krypton. In particular they wanted to know if I would switch to creating WPF components or stick exclusively with WinForms. Here I hope to clarify my current roadmap.

Krypton Roadmap
The immediate future for the Krypton Toolkit is to add some date/time related controls. In particular a standalone calendar control and a standalone datetimepicker plus a calendar element that can be used inside the KryptonContextMenu. A docking system will also be added that is provided as a commerical add-on and become part of the Krypton Suite product. I expect all this to be wrapped up as version 3.5 and to be delivered at the end of the year or not long after.

Further out will be version 4.0 and include more Toolkit controls such as a progress bar, track bar and scroll bars. Included will be improvements to the docking and workspace components. The initial release of the workspace and docking windows have a minimal feature set and so this release will build on those and add extra features. For example the Workspace needs a persistence mechanism as well as a maximized mode so users can concentrate on a single cell for a period of time. The due date for this would be around 3 or 4 months after version 4.0.

Release 4.0+ is not currently determined so I am open to feedback for deciding on the direction to take. I will be asking for feedback nearer the time and decide then if I should create a data grid, gauge controls etc. Maybe at this point we will see a Beta version of the next Office and Windows revisions and so that might throw up some requests.

Longer term I expect to keep improving and adding to the Krypton set of components, including the free Toolkit, for as long as there is demand for WinForms components. I expect this to be quite a few years into the future as many companies have invested heavily in WinForm applications and have no big need to switch over to something else. As a small company I can live on the niche position of being an active WinForm developer when other vendors have had to switch away because they have large teams to pay.

WPF Roadmap
There are two factors driving my WPF strategy. First is the current slow adoption of WPF for new projects and the second is the potential redundancy of any new controls that are created. The slow uptake means there is no panic to quickly create something just because your sales have disappeared. In fact my sales have steadily improved right from the first release. This means I can take a more measured approach and watch how the market shapes up before deciding on how to structure any offering.

How long will the WPF market last should it become the de facto standard for client applications? I would estimate that 10-15 years is not unreasonable as GDI has lasted much longer than that. To get the most bang for your buck you want to create components/controls that will be valuable and useful for that entire 10-15 years. Now if you look at all the vendors that have rushed out WPF Ribbon controls you can see that the effort was of little long term value. Microsoft have stated that they are creating a WPF Ribbon that should be released by the end of this year. Now unless the Microsoft version is really bad I imagine most developers would use the Microsoft version rather than pay for one. Given WPF is now the main focus for client apps at the Microsoft it means they will doubtless add additional controls over time.

My current thinking is that I will wait until around the middle of next year before starting any serious coding of WPF components. At that point I will concentrate on components that  provide long lasting value and minimize the chances of them becoming obsolete because of Microsoft. That might sound a hard proposition but I have several ideas for initial components that I think would be very handy for developers and are unlikely to ever come from Microsoft themselves.

Summary
I will be continuing development of Krypton for as long as there is demand for the WinForms components, which I anticipate being several years. Around the middle of next year I will start spending some of my time working on WPF but note that I will still be working on Krypton as well.

Obviously any strategy is subject to change depending on market conditions but this is my current thinking. I would be interesting in hearing your feedback. If you have any better ideas or see fundamental problems with this then don’t be afraid to speak up!