Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

461–470 of 577 posts

Re: Writing GUI apps for Windows is painful

#463
post #444

Earlier 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.

True, but they are optional and are not the parts you need to create a GUI as per the requirements in the OP. I assume CopperSpice does not include these components.

Re: Writing GUI apps for Windows is painful

#464

WPF 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…

Yeah, I've done custom skinned apps in WPF that were deployed via zip file. Unzip and run the exe. Worked fine and even did p/invoke. Either they are ignorant about MS windows development or just a fanciful idea about how it should work.

Re: Writing GUI apps for Windows is painful

#466

This reminded me of The Cherno’s Walnut library: https://youtu.be/-NJDxf4XwlQ

First of all, this is an immediate rendering library which is a very inefficient way of rendering the UI for any application that is not a videogame. You are rendering the UI 60 times a second, regardless of whether something changed or not. Most UI frameworks only update when something changes.

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

#468
post #383

Earlier 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.

Right. I want your app to have consistency with the platform I’m using. Not between all platforms.

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

#469
post #102

Earlier 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?

.NET 4.8 is the last .NET to be bundled with Windows. It's a legacy stack, but it exists on every Windows >= 10 so it is a legacy stack that makes deployables easy (just assume it is installed). (.NET 4.8 is the new VB6.)

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

#470
post #147

Earlier 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.

[deleted]
Post reply on HN