Unity.Windows.Forms

I am developing a port of System.Windows.Forms library from the Mono project for Unity3D environment. The project also includes porting of System.Drawing library. Currently the project is still in its early stages of development, but before starting developing I’ve done proof-of-concept, poorly compliant in terms of rendering (since rendering in SWF fully implemented through Drawing), but mostly compatible in other aspects that do not depend on other libraries. These early development have proven to myself - it is possible. And it’s worth a separate, full-fledged project.

The main objectives of this project:
• the maximum possible compatibility with SWF;
• additional features of Unity, like multitouch, 3D GUI.
• fixing some bugs in SWF (of course, so at the expense of compatibility, but I doubt that many will be upset).
• various ways of rendering - via a standard Unity GUI, GUI as an object scene, render to texture for the Pro version.
• various implementations - for PC, mobile platforms, WebPlayer.
• support for not only ingame GUI, but the Unity3D editor either.

Looks too ideal, isn’t it? But an ideal does not exist - various implementations have different degrees of support. Thus, it is obvious that when used a standard rendering through Unity GUI many features, such as render to texture, will be not available, as well, a projects for mobile platforms or WebPlayer would have significant limitations. But that doesn’t mean that for each platform you’ll have to create different GUI components - most limitations are implemented transparently to the program and you’ll just have to take into account the compatibility when coding your GUI.

This was preamble. Now to fable. I’ve got a small investment from my relatives for the project before, but, unfortunately, I’ve set unattainable deadline. In the near future investments will be exhausted and I will have to look for additional sources of finance, at worst case - get an underworking. Worst - as in this case development could be badly delayed, that I would not want to. I consider two options - either release the Unity.Drawing as a separate library or create a project on Kickstarter. Honestly, I can hardly imagine options for using Unity.Drawing without UWF, especially since that the first version will be far from 100% compatibility. Kickstarter would be preferable. Therefore, I would like to appeal a small poll here - how much you are interested in this project, whether you are ready to invest in it to get a discount (or a refund with interest if the amount of investment exceeds the cost of the license - about $ 100-200) at the end of the development?

P.S. I apologize for possible mistakes, English is not my native language.

What are the intended use cases for this project? Why would people need it?

Because of the same reason why people need any other GUI library. But, WinForms has many benefits: it is familiar to many .NET programmers, is well documented, has many custom open-source controls available on the internet (that easily could be slightly modified and recompiled to be used in UWF) and, unlike Unity GUI, allows to easily create new ones, it can be used to create a very customizable GUI. At last, it may be used in the Unity3D editor.

GUI has to be more like WPF than WinForms. WinForms neither looks good nor supports nice animations. On the other hand, Unity apps and games rarely need as elaborate controls as desktop apps do. I wouldn’t count on such library being popular.

I like the way SWF works. It’s quite easy to do something simple with SWF and at the same time complicated things aren’t getting more complicated. Unity GUI is appropriate only for simplest tasks. WPF is too complicated (and buggy), another GUIs are not so popular.
Any way, I’ll make UWF popular. Let’s say, I have no other choise.