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!
October 2nd, 2008 at 10:40 pm
Please Phil, can we have tabs which has a close button on the tab and the ability to swap the position of the tab, ASAP, then I’ll stop asking :) I am so in need of this.
October 2nd, 2008 at 11:02 pm
Part of adding docking will be allowing the tab reordering using the mouse. Adding per-tab button specs is also on the list!
October 2nd, 2008 at 11:05 pm
I think you’re right. WPF and Silverlight are very new technologies with many changes in the first few years. If you start to learn sth. in WPF, the next version is able to do this in a other way. Easier and faster than before. I think we have to be patient and start “coding” WPF when it’s sophisticated enough.
WinForms aren’t dead by now. This is what .net-developers (and vb, delphi …) are taught to develop and I think there are many developers which don’t want to switch in the next 5 years.
October 3rd, 2008 at 12:14 am
Phil,
A suggestion: Windows Mobile!
One can’t seriously think of writing a real Windows Mobile app without relying on a toolkit. The needs are fairly specific. Such as a customizable ListView.
The problem is that the Windows CE (underlying WM) designers cut into the native messages that allow to easily customize the look of a listview without going the full owner drawn way. And since WM apps designers have to deal with small screen estate, intuitivity of the UI is a must. Hence the need for self speaking lists and stuff… which we don’t have.
You don’t imagine how frustrating it is to see properties and methods disappear from .NET MSDN docs whenever you select the ‘Compact Framework’ doc filter :-(
On the other hand, there’s desktop stuff we don’t need. Such as fancy buttons: A smart WM app uses only the 2 so-called Soft Keys, which are a combination of buttons and menu placed at the bottom of the screen.
The interesting news for you is that there are amazingly few actors on this fast growing market. The toolkit I used is fairly good (fairly. not more) but the support actually sucks.
You certainly have a role to play and money to make in there.
Regards,
October 3rd, 2008 at 3:11 am
Hi all,
@Serge. I am at first a Windows Mobile developper with the .NET CF. I would be very happy to see Krypton on it, but it doubt it is technically feasible or at least as nice as it is on the desktop. Moreover, the code will require a lot of PInvoke that could still slow down the app, but that would be definitively an interesting idea. For customizing listviews, take a look on the Alex Yakhnin blog, there are quite a few really interesting samples to extend its basic functionnality, but it is always limited by the wrapping around the native control. Resco has great components, and also OpenNETCF (for a low price). There is another thing, we still do not know how things will change with WM7.
@All : I am happy you will still support the Winforms. The next addtions to the toolkit are really welcomed (Progressbar, scollbars,…)
For WPF, I must admit I do not know how it is, if it’s great or not.
October 3rd, 2008 at 2:38 pm
Phil,
I think you’re very wise to take a slower approach to WPF. Not because it’s lacking, but because WPF things will have set in by then, matured.
My suggestion for Krypton in the future is not new components — a progress bar and scrollbars would be nice, but not required.
No, my suggestion as a long-time Krypton user and purchaser is this: give the whole toolkit support for animation: transparency, movement, control size, color transitions.
October 3rd, 2008 at 4:36 pm
I am a non-professional programmer but my desire is for a scheduling component to go along with the toolkit. Then I can build the app I can’t find a suitable version of – a shift rostering program. With the toolkit, upcoming calendar controls, it will look great.
October 4th, 2008 at 12:23 am
Phil, I wanted to thank you for this post. It is so refreshing to be able to “see” into the mind of a 3rd party provider and understand why you are doing what you do. With most companies, we are left to blindly follow without understanding why. Thank you for being so up front and open to our feedback.
October 4th, 2008 at 12:24 am
Hi Phil,
to add transparency support is what I would have sugested as well, but primary I’m glad to see Date/Time related controls on your roadmap (that’s what we need urgent), as well as calendar functionality. Perhaps this would prevent me from rewriting my own, in VB6 developed calender for dotNet (what I don’t know when to do). Maybe we can provide some input on needed functionality when you start planning or implementing, I think we have some good Ideas.
Although WPF impesses with it’s graphical possibilities I can not imagine when it woud be necessary for us to have controls on this basis …
October 4th, 2008 at 7:21 am
@Cocotteseb.
As I wrote, the purpose of a WM toolkit would be somehow different than a Desktop toolkit. And, yes, it’s feasible since some do it! The problem is that you have to go through the whole owner-drawn way, which nobody would do. Unless you’re a specialist such as Phil.