4 ms·

From just glancing at it, it looks like this is targeted at developers creating WinUI applications and turning those into cross platform applications. WinUI be

by cdash 6y ago

From just glancing at it, it looks like this is targeted at developers creating WinUI applications and turning those into cross platform applications. WinUI being the UI platform that Microsoft seems to be pushing on windows these days.

DaiPlusPlus 6y ago
> WinUI being the UI platform that Microsoft seems to be pushing on windows these days. WinUI doesn't sit well with me - it has the same problem that all the other "user-mode" UI frameworks have: it isn't a system-service, so once your app ships it's frozen in time and won't benefit from new features added to native widgets and controls (e.g. if you run a well-designed MFC EXE last compiled for Windows 2000 - but tweak the embedded manifest resource file to load the updated CommonControls and Windows 10 compatibility - it will still look good today and fit-in with an MFC program created new last week (I note it will look "good" - not "amazing" - because Microsoft decided to take Windows 10's native widgets downmarket since Windows 8, ugh...). Could be worse - at least it's not Java AWT or Swing. What on earth was Sun thinking when they designed that?
- pjmlp 6y ago
  Basically outside NeWS and NeXTSTEP, most UNIX companies were hardly known for actually being able to design proper GUI frameworks. Give me raw Win32 over Xlib/Athena/Motif any day of the week.
  - DaiPlusPlus 6y ago
    > Give me raw Win32 over Xlib/Athena/Motif any day of the week. I share your sentimental attitude, but looking at the past 10+ years of "post-native" desktop UI development being done in Electron, at al, it really does look like the days of platform-specific proprietary UI frameworks and toolkits are coming to an end. Modern HTML+CSS is a far more expressive medium for usable application UI layouts. Trying to build a "responsive" UI in VB6 is essentially impossible, for example. Even from a user's perspective I'm glad that fixed-size, DPI-unaware dialogs are done-away with. I can't complain that much though - I don't miss writing low-level Win32 message-pumps - nor being limited by GDI's horribly outdated nature (fun-fact: it's impossible to build applications that support 10-bit color with GDI despite GDI's built-in support for different bpp values, because GDI assumed 24bpp / 8bpc was enough for anyone forever). There's now only a few things missing from HTML+CSS that would enable true native-like applications: borderless sub-windows (think: for context-menus that can extend beyond the parent web-browser's client area on your desktop) and native macOS main-menu support (which feels like an anachronism given the large mouse-movements needed with today's humongous desktop display sizes).
    - pjmlp 6y ago
      If you look for it, there is plenty of work to be found doing native GUI programming. I have spent 2014 - 2018 doing Forms/WPF GUIs for life sciences labs, and at least for those customers I can assure they aren't going to switch to Electron, more likely Qt or WinUI when time comes.
      - DaiPlusPlus 6y ago
        You've betrayed your own point by admitting that though: WinForms and WPF aren't native - (well, WinForms is a a thin abstraction layer, but still not truly native). If you're using WPF today you can probably switch to Electron without your users noticing anything (besides a 10x increase in memory usage...)
        pjmlp 6y ago
        They are native UIs of the Windows platform, built on top of Win32, GDI+ and DirectX. There is so much that the Web still fails short of WPF.
        Const-me 6y ago
        > you can probably switch to Electron without your users noticing anything GPU support is not good enough in the browsers. Even 12 years old Direct3D 11.0 is way better than the current WebGL. In WPF, it’s relatively easy to render a dynamic texture with Direct3D 11 or 12, then pass it to WPF to compose it into the GUI, without ever downloading pixels from VRAM. Similar for compute shaders. You don’t need WPF to integrate DirectCompute, but you do need convenient native interop. These C structures, typed arrays and unmanaged pointers are all over the API surface. Not sure JavaScript is good enough for the job, the language and VM were designed for very different requirements.
        jmnicolas 6y ago
        > If you're using WPF today you can probably switch to Electron without your users noticing anything A WPF app will load much faster and feel more integrated (more Windows like) than an electron app. I have a C# / WPF app that I optimized to the best of my capacity but that still needs about 1 minute to compute data. I shudder to think how long JS would take to do the same job.
- datavirtue 6y ago
  They were looking at the dominate platform at the time for corporate dev...visual basic. Not really sure why there was so much hate on swing, probably from the people who never used it. No performance issues, looked good enough for users, theme able. I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native. AWT was slow and ugly but not swing.
  - DaiPlusPlus 6y ago
    > Not really sure why there was so much hate on swing, probably from the people who never used it. No performance issues, looked good enough for users, theme able. I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native. AWT was slow and ugly but not swing. Let's unpack this... > Not really sure why there was so much hate on swing Swing itself isn't bad (compared to its predecessor in AWT) but Swing is still an abstraction over multiple different and incompatible desktop UI toolkits - therefore it has to compromise. > probably from the people who never used it Used it as an end-user, or used it as an applications developer, though? The last time I used Swing was around 2010 - and I admit that I haven't stayed on-top of new developments, but I assume that Sun/Oracle switched emphasis away from Swing over to JavaFX (their WPF-compete) and that Swing hasn't changed much (at a fundamental level) much. Please correct me if I'm wrong. > No performance issues Yes-and-no. Things like repainting a busy charting component is fast enough, sure - but one thing about Swing that sticks out like a sore thumb is abysmally slow window repainting when a window is resized - I first noticed this when I was a lame warez kiddie using Limewire almost 20 years ago (wow...): actively resizing the Limewire window would cause the JVM to pause repainting the window and just draw a black background color until a few hundred milliseconds after I finished resizing. I've noticed similar behaviour in other Swing applications. It isn't pretty. Especially on macOS where users expect to be able to smoothly resize application windows. > looked good enough "good enough" is not exactly the best review in the world > themeable Yes, but who honestly goes through the effort to make an entire theme just for their own application? That's only affordable if you're a software giant or a company whose brand identity is heavily based on their software UX (and if that was the case, they wouldn't be using Java for desktop applications). > I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native This may have been true in the final months of Windows 98/Me and Windows 2000, but Swing's inability to correctly reimplement (or even wrap) Windows XP's visual styles (especially the animated controls and when running outside of 96dpi mode) was exactly what gave Swing that uncanny-valley feeling (granted - and hypocritically - Microsoft's own WPF is also guilty of this, which is why I avoided it entirely until recently).
- WorldMaker 6y ago
  People complained that UWP was too tied to Windows Updates and control updates required major Windows Updates (and who has time to wait for corporate to deploy this year's Windows version?). So Microsoft addressed that by lifting and shifting most of UWP's UI framework out of the OS updates cycle into WinUI 3. It's almost funny to see complaints come full circle back to things should be OS managed and not in a developer cycled framework.
jgilias 6y ago
Ok. I think I'd rather go for .NET MAUI when it comes out, as native has a better look and feel pretty much always. Apparently though .NET MAUI is set for .NET 6 which doesn't have a release schedule. So there's that. I haven't used Xamarin.Forms, what's the problem with it?
- blackoil 6y ago
  .Net has yearly release schedule, so 6 will be in Nov 2021. https://devblogs.microsoft.com/dotnet/net-core-releases-and-support/ https://devblogs.microsoft.com/dotnet/net-core-releases-and-...
- pjmlp 6y ago
  Xamarin.Forms apparently has some stability issues on the Mac. In any case, MAUI is Xamarin.Forms extended to the desktop, the name changed for marketing purposes.
  - nbevans 6y ago
    We've been using Xamarin Forms on the (UWP) desktop for a few years now. It's pretty great. There are bugs yes, but so do all these magic cross-platform UI frameworks. They're investing heavily into MAUI to fix a lot of these things.
    - nxc18 6y ago
      Great has not been my experience with forms UWP. Lots and lots of bugs in the UWP components forces you to abandon most of the things you need to make a nice iOS/Android UI. Unless you’re prototyping or really don’t care at all about UX I don’t see why you wouldn’t write the UI in the native framework. And if you don’t care at all about UX then HTML+CSS+JS is probably a better choice.
      - nbevans 6y ago
        We've been working on our Xamarin Forms based product since the first beta in 2014. We released to Android first. Then in 2018 we built a UWP variant of our app. This process barely took a week if I don't include the technical debt that took an extra week to sort out. Then in 2019 we built an iOS variant of our app too - again barely taking a week to do so. Xamarin Forms let us build 4 years worth of tech for Android only. And then, when we had time and the customer demand to do so, with a small amount of work - port our app to 2 other platforms in fairly short order. I don't know of any other platform that could do this - particularly when considering the years involved. Our app uses local databases on the device - so a web based app would not have cut it. And our app has roots in 2014 tech when many possible alternate approaches did not exist yet.
intricatedetail 6y ago
Is there a guarantee that this is not going to share the fate of WPF?
- pjmlp 6y ago
  Like still being maintained and supported on latest Windows and .NET versions?
  - moogly 6y ago
    The problem is they never truly iterated on the product. There are a hundred ways you could simplify and improve WPF.
    - pjmlp 6y ago
      Feel like contributing? https://github.com/dotnet/wpf https://github.com/dotnet/wpf
      - moogly 6y ago
        No thanks, it's been dead for a while.
        pjmlp 6y ago
        On the contrary, plenty of gigs available in Europe and it is still being updated. Yes the team is small, still great than zero and more mature than plenty of wannabe FOSS GUI frameworks.
        WorldMaker 6y ago
        There are updates to WPF (and WinForms) in .NET Core 5. It's probably more accurately "undead" than "dead".
        moogly 6y ago
        I'll buy "undead", since it's just maintenance (just check their roadmap).

by cdash 6y ago

DaiPlusPlus 6y ago

> WinUI being the UI platform that Microsoft seems to be pushing on windows these days. WinUI doesn't sit well with me - it has the same problem that all the other "user-mode" UI frameworks have: it isn't a system-service, so once your app ships it's frozen in time and won't benefit from new features added to native widgets and controls (e.g. if you run a well-designed MFC EXE last compiled for Windows 2000 - but tweak the embedded manifest resource file to load the updated CommonControls and Windows 10 compatibility - it will still look good today and fit-in with an MFC program created new last week (I note it will look "good" - not "amazing" - because Microsoft decided to take Windows 10's native widgets downmarket since Windows 8, ugh...). Could be worse - at least it's not Java AWT or Swing. What on earth was Sun thinking when they designed that?

pjmlp 6y ago
Basically outside NeWS and NeXTSTEP, most UNIX companies were hardly known for actually being able to design proper GUI frameworks. Give me raw Win32 over Xlib/Athena/Motif any day of the week.
- DaiPlusPlus 6y ago
  > Give me raw Win32 over Xlib/Athena/Motif any day of the week. I share your sentimental attitude, but looking at the past 10+ years of "post-native" desktop UI development being done in Electron, at al, it really does look like the days of platform-specific proprietary UI frameworks and toolkits are coming to an end. Modern HTML+CSS is a far more expressive medium for usable application UI layouts. Trying to build a "responsive" UI in VB6 is essentially impossible, for example. Even from a user's perspective I'm glad that fixed-size, DPI-unaware dialogs are done-away with. I can't complain that much though - I don't miss writing low-level Win32 message-pumps - nor being limited by GDI's horribly outdated nature (fun-fact: it's impossible to build applications that support 10-bit color with GDI despite GDI's built-in support for different bpp values, because GDI assumed 24bpp / 8bpc was enough for anyone forever). There's now only a few things missing from HTML+CSS that would enable true native-like applications: borderless sub-windows (think: for context-menus that can extend beyond the parent web-browser's client area on your desktop) and native macOS main-menu support (which feels like an anachronism given the large mouse-movements needed with today's humongous desktop display sizes).
  - pjmlp 6y ago
    If you look for it, there is plenty of work to be found doing native GUI programming. I have spent 2014 - 2018 doing Forms/WPF GUIs for life sciences labs, and at least for those customers I can assure they aren't going to switch to Electron, more likely Qt or WinUI when time comes.
    - DaiPlusPlus 6y ago
      You've betrayed your own point by admitting that though: WinForms and WPF aren't native - (well, WinForms is a a thin abstraction layer, but still not truly native). If you're using WPF today you can probably switch to Electron without your users noticing anything (besides a 10x increase in memory usage...)
      - pjmlp 6y ago
        They are native UIs of the Windows platform, built on top of Win32, GDI+ and DirectX. There is so much that the Web still fails short of WPF.
      - Const-me 6y ago
        > you can probably switch to Electron without your users noticing anything GPU support is not good enough in the browsers. Even 12 years old Direct3D 11.0 is way better than the current WebGL. In WPF, it’s relatively easy to render a dynamic texture with Direct3D 11 or 12, then pass it to WPF to compose it into the GUI, without ever downloading pixels from VRAM. Similar for compute shaders. You don’t need WPF to integrate DirectCompute, but you do need convenient native interop. These C structures, typed arrays and unmanaged pointers are all over the API surface. Not sure JavaScript is good enough for the job, the language and VM were designed for very different requirements.
      - jmnicolas 6y ago
        > If you're using WPF today you can probably switch to Electron without your users noticing anything A WPF app will load much faster and feel more integrated (more Windows like) than an electron app. I have a C# / WPF app that I optimized to the best of my capacity but that still needs about 1 minute to compute data. I shudder to think how long JS would take to do the same job.
datavirtue 6y ago
They were looking at the dominate platform at the time for corporate dev...visual basic. Not really sure why there was so much hate on swing, probably from the people who never used it. No performance issues, looked good enough for users, theme able. I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native. AWT was slow and ugly but not swing.
- DaiPlusPlus 6y ago
  > Not really sure why there was so much hate on swing, probably from the people who never used it. No performance issues, looked good enough for users, theme able. I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native. AWT was slow and ugly but not swing. Let's unpack this... > Not really sure why there was so much hate on swing Swing itself isn't bad (compared to its predecessor in AWT) but Swing is still an abstraction over multiple different and incompatible desktop UI toolkits - therefore it has to compromise. > probably from the people who never used it Used it as an end-user, or used it as an applications developer, though? The last time I used Swing was around 2010 - and I admit that I haven't stayed on-top of new developments, but I assume that Sun/Oracle switched emphasis away from Swing over to JavaFX (their WPF-compete) and that Swing hasn't changed much (at a fundamental level) much. Please correct me if I'm wrong. > No performance issues Yes-and-no. Things like repainting a busy charting component is fast enough, sure - but one thing about Swing that sticks out like a sore thumb is abysmally slow window repainting when a window is resized - I first noticed this when I was a lame warez kiddie using Limewire almost 20 years ago (wow...): actively resizing the Limewire window would cause the JVM to pause repainting the window and just draw a black background color until a few hundred milliseconds after I finished resizing. I've noticed similar behaviour in other Swing applications. It isn't pretty. Especially on macOS where users expect to be able to smoothly resize application windows. > looked good enough "good enough" is not exactly the best review in the world > themeable Yes, but who honestly goes through the effort to make an entire theme just for their own application? That's only affordable if you're a software giant or a company whose brand identity is heavily based on their software UX (and if that was the case, they wouldn't be using Java for desktop applications). > I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native This may have been true in the final months of Windows 98/Me and Windows 2000, but Swing's inability to correctly reimplement (or even wrap) Windows XP's visual styles (especially the animated controls and when running outside of 96dpi mode) was exactly what gave Swing that uncanny-valley feeling (granted - and hypocritically - Microsoft's own WPF is also guilty of this, which is why I avoided it entirely until recently).
WorldMaker 6y ago
People complained that UWP was too tied to Windows Updates and control updates required major Windows Updates (and who has time to wait for corporate to deploy this year's Windows version?). So Microsoft addressed that by lifting and shifting most of UWP's UI framework out of the OS updates cycle into WinUI 3. It's almost funny to see complaints come full circle back to things should be OS managed and not in a developer cycled framework.

jgilias 6y ago

Ok. I think I'd rather go for .NET MAUI when it comes out, as native has a better look and feel pretty much always. Apparently though .NET MAUI is set for .NET 6 which doesn't have a release schedule. So there's that. I haven't used Xamarin.Forms, what's the problem with it?

blackoil 6y ago
.Net has yearly release schedule, so 6 will be in Nov 2021. https://devblogs.microsoft.com/dotnet/net-core-releases-and-support/ https://devblogs.microsoft.com/dotnet/net-core-releases-and-...
pjmlp 6y ago
Xamarin.Forms apparently has some stability issues on the Mac. In any case, MAUI is Xamarin.Forms extended to the desktop, the name changed for marketing purposes.
- nbevans 6y ago
  We've been using Xamarin Forms on the (UWP) desktop for a few years now. It's pretty great. There are bugs yes, but so do all these magic cross-platform UI frameworks. They're investing heavily into MAUI to fix a lot of these things.
  - nxc18 6y ago
    Great has not been my experience with forms UWP. Lots and lots of bugs in the UWP components forces you to abandon most of the things you need to make a nice iOS/Android UI. Unless you’re prototyping or really don’t care at all about UX I don’t see why you wouldn’t write the UI in the native framework. And if you don’t care at all about UX then HTML+CSS+JS is probably a better choice.
    - nbevans 6y ago
      We've been working on our Xamarin Forms based product since the first beta in 2014. We released to Android first. Then in 2018 we built a UWP variant of our app. This process barely took a week if I don't include the technical debt that took an extra week to sort out. Then in 2019 we built an iOS variant of our app too - again barely taking a week to do so. Xamarin Forms let us build 4 years worth of tech for Android only. And then, when we had time and the customer demand to do so, with a small amount of work - port our app to 2 other platforms in fairly short order. I don't know of any other platform that could do this - particularly when considering the years involved. Our app uses local databases on the device - so a web based app would not have cut it. And our app has roots in 2014 tech when many possible alternate approaches did not exist yet.

intricatedetail 6y ago

Is there a guarantee that this is not going to share the fate of WPF?

pjmlp 6y ago
Like still being maintained and supported on latest Windows and .NET versions?
- moogly 6y ago
  The problem is they never truly iterated on the product. There are a hundred ways you could simplify and improve WPF.
  - pjmlp 6y ago
    Feel like contributing? https://github.com/dotnet/wpf https://github.com/dotnet/wpf
    - moogly 6y ago
      No thanks, it's been dead for a while.
      - pjmlp 6y ago
        On the contrary, plenty of gigs available in Europe and it is still being updated. Yes the team is small, still great than zero and more mature than plenty of wannabe FOSS GUI frameworks.
      - WorldMaker 6y ago
        There are updates to WPF (and WinForms) in .NET Core 5. It's probably more accurately "undead" than "dead".
        moogly 6y ago
        I'll buy "undead", since it's just maintenance (just check their roadmap).