Earlier quoted context omitted.
The only good thing to say about that is it removes the stupidity of using Electron (or the Microsoft Edge equivalent) for built-in Windows apps and the Start Menu. SMH.
Whoever was responsible for that should be fired.
Windows native app development is a mess
231–240 of 481 posts
Re: Windows native app development is a mess
#232Earlier quoted context omitted.
First, dark mode is for people who set their screen brightness too high. Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed becau…
Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not. Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in…
Re: Windows native app development is a mess
#233Earlier quoted context omitted.
> Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically? You need a commercial license for that, but yes you could. But since applications are typically distributed with install bundles that put into application-local program files directories, it's not super-important as long as you only cherry-pick the Qt libraries you need.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt. I've observed many people spreading this misinformation about on…
Also, modern compilers make this method much harder to use. It is much harder to stably relink object files like that than to just use the normal dynamic link method.
Re: Windows native app development is a mess
#234Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper. Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuan…
Microsoft released it open source later on. Looking at the repository, looks like it has been kept up and maintained, up to version 10 now.
Re: Windows native app development is a mess
#235I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…
Re: Windows native app development is a mess
#236> And from what I can tell, neither are most developers. The Hacker News commentariat loves to bemoan the death of native apps. But given what a mess the Windows app platform is, I’ll pick the web stack any day, with Electron or Tauri to bridge down to the relevant Win32 APIs for OS integration. Well yes as a user I prefer native apps for their performance. It's clearly a mess to develop native apps as the article sh…
When Microsoft themselves use electron to develop apps what expectations can we have on other devs?
Re: Windows native app development is a mess
#237Re: Windows native app development is a mess
#238Earlier quoted context omitted.
Why single out WebViews? Would you consider Flutter native? It renders widgets on its own just like a WebView does.
Most toolkits, including WebUI 3.0, render widgets on their own, so you can't distinguish just on that. I'd say anything written in an interpreted language is not native, and Javascript falls into that category. Dart at least is possible to compile ahead of time, and so is C#.
You can also hook a WebView up directly to a low-level language and skip Javascript entirely, so does that mean Rust + WebView = Native?
Re: Windows native app development is a mess
#239But after I had the msi and dmg files, my non-techy colleagues couldn't install the apps because they weren't signed. The workaround for Mac was fine (remove the quarantine attribute on the installer) but for Windows my colleague had to disable Smart App Control (SAC), which cannot be re-enabled without re-installing Windows.
I get the point of these protections, but the difficulty of getting past them surprised me. I thought that on Mac you should just go to settings -> security and click 'Allow Anyway'. And that on Windows you'd get a GUI warning that would need admin privileges to get past. But MacOS needed a terminal command, and Windows needed a control panel setting change.
Re: Windows native app development is a mess
#240Earlier quoted context omitted.
>Native means system libraries only. Since when? To me, anything not webview-based is native, though you have varying degrees of integration into the platform.
Why single out WebViews? Would you consider Flutter native? It renders widgets on its own just like a WebView does.