SoylentNews

Microsoft Open-Sources WPF, WinForms and WinUI

posted by takyon on Wednesday December 05 2018, @09:10PM   
from the underworld-refrigeration dept.

Rich writes:

In a surprise move at the Build 2018 conference, Microsoft have announced that three key components of the Windows user interface are now open-sourced. Kevin Gallo, MS VP for the Windows Developer Platform sums it up in a blog entry.

Announcing Open Source of WPF, Windows Forms, and WinUI at Microsoft Connect(); 2018

The newly opened-up components are critical for writing desktop applications and have so far been Windows-only. Based on C# and the .NET framework, especially WPF is generally considered to be reasonably good. Interest from beyond the Windows ecosystem might appear: when will we see ports to the Linux and Mac platforms, and what would it mean to their platform-specific toolkits GTK and Cocoa?

WPF = Windows Presentation Foundation

---

Original Submission

• Re:Interesting bias Re:Interesting bias (Score: 1, Informative) by Anonymous Coward on Thursday December 06 2018, @02:38PM (1 child)

  by Anonymous Coward on Thursday December 06 2018, @02:38PM (#770651)

  Have you ever seen the sheer amount of crazy boiler plate that Glib and GTK requires. It is not pretty. I would say that it is the ugliest framework i ever worked with. And believe me i have done a lot

  GTK+ is a bit special in the GUI toolkit world because it is one of very few toolkits with a C API. Like if you want to write a modern GUI widgety application in C[*] it's pretty much your only choice, because basically nobody sane writes GUI toolkit bindings for C. You can't compare writing a GTK+ application in C with, say, a Qt application in C because you can't write a Qt application in C.

  If you want to compare it with other toolkits you should be compare bindings for the different toolkits in the same language. For example, you can compare C++ bindings of GTK+ (gtkmm) with a native C++ toolkit like Qt. Or compare python bindings for both toolkits (e.g,., PyGOobect versus PyQt). Basically all the GTK+ boilerplate goes away when you use any language other than C.

  [*] one might want to write such an application because they are a masochist.

  Parent

  Starting Score:	0		points
  Moderation		+1
  Informative=1, Total=1
  Extra 'Informative' Modifier		0
  Total Score:		1

• Re:Interesting bias (Score: 2) by aiwarrior on Friday December 07 2018, @08:25AM

  by aiwarrior (1812) on Friday December 07 2018, @08:25AM (#771077) Journal

  > If you want to write a modern GUI widgety application in C
  This is the point. Nobody wants to write a gui application in C. If they want C*ish* and baremetal go with C++ and write C there. No performance impact. For all the flaws of C++ you can really mostly take what you want from the language and it's not wrong.

  gtkmm is very nice until you do anything serious, at which point you will find: Missing documentation, missing implementation. This is terrible because the risk of starting a project in such an enviroment makes the whole platform useless even for toy stuff. Yep i failed in toy stuff with gtkmm and stuck with pure C GTK. For PyGObject i do not know but i dread, absolutely dread GTK interfaces(Gdk, Cairo, Gstreamer) incompleteness.

  I think the point of the other poster, where Compatibility is orthogonal to Usability, is a bit more to the point except it has been proven wrong and the weights should not 50-50. What about QT? What about now the .NET

  It is true that C is the only language where you can have easy management of ABI for other languages to hook into. But the keyword is easy. Designing/implementing bindings is supposed to be something very few users do. So, if it was harder to do in favor for easiness to use normal usage i think this would be an acceptable trade off.

  Thanks for the argument anon :)

  Parent