Writing GUI apps for Windows is painful
461–470 of 577 posts
Re: Writing GUI apps for Windows is painful
#462Re: Writing GUI apps for Windows is painful
#463Earlier quoted context omitted.
Qt is also available under the LGPL. There is no license advantage to using CopperSpice. I'm not sure what GP is referring to.
Some parts of Qt are GPL only.
Re: Writing GUI apps for Windows is painful
#464WPF is still a perfectly viable solution > The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code). I don’t understand how that makes WP…
Re: Writing GUI apps for Windows is painful
#465Re: Writing GUI apps for Windows is painful
#466This reminded me of The Cherno’s Walnut library: https://youtu.be/-NJDxf4XwlQ
Secondly, there are things in GUI frameworks that most people don't think about, such as accessibility. Windows has a builtin accessibility API where apps can declare the objects being shown on the screen, so that screen readers can interact with the application. I'm pretty sure this guys framework doesn't have that.
Re: Writing GUI apps for Windows is painful
#467Actually a lot of people are saying that Linux is the best platform for developing GUIs.
Re: Writing GUI apps for Windows is painful
#468Earlier quoted context omitted.
> There are exceptions, for very rich dense UI, for UIs that need to be cross-platform That’s not exceptional at all. That’s completely normal requirements that are probably in the majority. Does Microsoft themselves build their apps this way?
Most applications would be fine with a button on Windows looking like a Windows button, a button on Mac looking like a Mac button, a button on Android looking like a Material Design button and a button on iPhone looking like a UIKit button. You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.
With the exception of games try to use the native GUI. It’s the best choice most of the time.
Re: Writing GUI apps for Windows is painful
#469Earlier quoted context omitted.
Yeah, I can confirm that writing windows GUI apps is not at all painful for me. I still use Windows Forms in .NET 4.8 and my executables are < 1mb, Visual Studio's form designer is very easy to use, you can subclass all the .NET UI controls and customize them however you want. There's always been accessibility and even support for high DPI.
>I still use Windows Forms in .NET 4.8 and my executables are Do you need to ship any supporting files separately, along with the app? And is .NET 4.8 or higher already on Windows PCs?
With .NET 9 right around the corner, how far behind the legacy stack is only increases.
.NET > 5 will never be installed out of the box on Windows PCs. The trade offs to that concession however are: cross-platform support, better container support, easier side-by-side installs support ("portable" installs). .NET > 7 can do an admirable job AOT compiling single-file applications. For a GUI app you probably aren't going to easily get that single-file self-contained and generally don't need a lot of specific OSes or things installed at the OS level. Each recent version of .NET has been working to improve its single-file publishing and there may be advances to come.
Re: Writing GUI apps for Windows is painful
#470Earlier quoted context omitted.
> Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK. I've been saying for a while now that the open source world would have benefited if more effort than what went into GNUStep had been focused on copying Cocoa to the point that it rather than GTK or Qt had been the toolkit of choice for the…
If anything is going to get copied by Linux as is... it'll be Win32 API so mono / C# stuff can bind directly to that, and Mac/OSX will be even more isolated. For something to be portable everywhere it'll have to be an industry standard that the existing industry buys into.