[IronPython] Roadmap and updates

Curt Hagenlocher curt at hagenlocher.org
Tue Aug 5 04:50:32 CEST 2008


XAML is really just an XML-based object persistence format.  It's not
directly tied to the display technology that it's mostly used for, which is
"WPF" or "Windows Presentation Foundation".  It's really WPF that should be
compared to Windows Forms -- you can use WPF without writing a single line
of XAML (or having the designer write it on your behalf).

If you're used to using the Win32 API or a thin wrapper over it like MFC,
then Windows Forms is a lot closer to what you know already.  That's because
Windows Forms itself is a (somewhat thicker) wrapper over the same Win32
API.  By contrast, WPF is a UI framework that's been redesigned from the
ground up.  Individual elements on a WPF window aren't represented by an
window handle; there's only one HWND at the top which effectively provides a
blank canvas for WPF to draw on.

There are probably hundreds of thousands of applications built on USER32.DLL
and/or Windows Forms.  The odds that Microsoft abandons all of these
applications are pretty low -- it is the applications, after all, that make
the platform what it is.  And although WPF is in many respects a much
better-to-develop-for architecture than Windows Forms, it also isn't perhaps
quite as mature -- and there are a few things that are still more easily
done using Windows Forms than WPF, particularly in a line-of-business-style
application.

With respect to IronPython, we don't have much to say about the platform as
a whole.  You can execute just about any .NET code from within IronPython --
whether that's Windows Forms, WPF, WCF, WF, Managed DirectX or the CLR-based
technologies that are just being invented now.  So as long as Windows Forms
exists, you'll be able to use it from IronPython.

If your specific concern is related solely to Harry's comment about the
Visual Studio integration work being more difficult for the Windows Forms
designer than for the WPF designer, then I think you've read a little too
much into what he said.  Our intent is to support the Windows Forms
designer.  It may be that -- due to its quirks -- we're not able to do so in
the early previews of the work, but I don't think that any of us would
consider the integration done if it was WPF-only.

Until then, you can always do what I understand Resolver Systems did: save
your forms as C# and manually copy the generated code into your Python
classes.  The initialization code is so generic and predictable that you
don't have to do much more than lop the semicolons off the ends of the
lines.


Disclaimer: I am a Microsoft employee, but I have absolutely no inside
knowledge on any of the topics I've written on here other than those related
directly to IronPython.

On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe <maxyaffe at comcast.net> wrote:

> Note:  I originally wrote this to Harry Pierson directly who asked that I
> post it publically. I hope it doesn't come off as too inflamatory.
>
> Harry - Thanks for the roadmap and the latest update.  It clarifies a
> particular issue that I'm having with deciding whether to adopt Iron Python
> and .Net for that matter.  My particular application is a scientific
> instrument control and data analysis package.  It runs on Windows now using
> various older MS technologies (dating back to Windows 2.3!).  It will not
> need to run from a web browser, mainly because of the requirements for
> instrument control.  The application is highly scripted using a dynamic
> language of my own devising derived from Smalltalk and remarkably similar
> to
> Python.
>
> I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my
> technology.  However, I wanted to see what Microsoft had to offer.
>  WinForms
> + Python seems to be the best fit for my technology because of the need to
> manipulate data tables and my desire to avoid the web.  Silverlight just
> doesn't offer me any advantage and seems to be directed at pretty pictures
> and sounds.  It also doesn't seem to handle the kinds of user/data
> interaction I need.  XAML also doesn't seem to offer any advantage for my
> code, or if it does, it certainly isn't clear what it might be other than a
> YAOUHD (yet another obese, unreadable HTML derivative).  Your roadmap,
> however, seems to deprecate WinForms.  I'm worried that IronPython and
> Microsoft are going to cut WinForms adrift just when I'm about to make a
> major investment in it.  This might be the best approach for Microsoft
> because it seems the "community" is mainly interested in pictures, sounds,
> and the web. But I need something more classical.
>
> I'd appreciate your comments and direction.
>
> Max Yaffe
> Gamry Instruments, Inc.
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080804/70d9facf/attachment.html>


More information about the Ironpython-users mailing list