Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

Post reply on HN
Print view View original

321–330 of 577 posts

Re: Writing GUI apps for Windows is painful

#321

Post by gyomu »

graynk wrote: post #318

Writing GUI apps for anything is painful, if we’re being honest. To this day I haven‘t seen a single good GUI framework for any of the platforms that I‘ve tried. Flutter feels nice though

UIKit has a few frustrating details, but overall it stands tall above the competition.

For a long time the main downside was that you had to deal with Objective C, which is a turnoff for some people.

Swift solved all this, and writing UIKit in Swift is mostly a joy. Sadly now SwiftUI is the new shiny thing, and it’s a major downgrade in most dimensions save for a few.

A cross platform framework that reuses UIKit conventions and supports all modern languages (C++/Rust/Go/Python/Nim) would be the dream.

Re: Writing GUI apps for Windows is painful

#323

Post by TJSomething »

throwaway2037 wrote: post #303
elpocko wrote: post #55

Earlier quoted context omitted.

Dear ImGui is for development/debug tools, not an UI for the end-user. It's great for small projects as long as you don't care about accessibility, or proper keyboard support, or adherence to standard UI conventions, or support for devices without GPUs, proper font rendering, etc. ...

> proper keyboard support Specifically, what does this mean?

I currently see two international keyboard issues:

- French Keyboard and Backend SDL2 - Several keys are not checkable with IsKeyDown

- Wrong ImGuiKey keydown indexes reported from Win32 backend for some keys when using UK keyboard with UK keyboard layout

There are also 2 issues with IME:

- Marked Text / SDL_TEXTEDITING Event / IME Composition support

- Backspace handling by text widget in default Windows IME environment.

Re: Writing GUI apps for Windows is painful

#324

Post by madduci »

Lariscus wrote: post #230

I have a very low opinion of developers who decry having to pay for a commercial licence for otherwise LGPL licensed software libraries. They expect to be paid for their work, and ensure that by creating closed source software. That's fair enough. Yet, the devs that solved the actually difficult parts of creating a UI library have to be utter saints who freely bestow a gift of code upon the world.

Exactly this.

Qt is amazing, so if your requirements are so strict in terms of space and you know/like Qt, investing in the license, or make the product open source, shouldn't be an issue here.

Re: Writing GUI apps for Windows is painful

#325

Post by pjmlp »

glzone1 wrote: post #284
pjmlp wrote: post #214

Earlier quoted context omitted.

Nope, the GUI story is so bad, that at BUILD 2024, WPF was made again an official Windows GUI framework for .NET devs, see BUILD 2024 sessions regarding Windows programming.

Haha.. That is too funny - I haven't been following this closely anymore. It's honestly wild. Does WPF still do data binding by reflection? I can usually "feel" a WPF app if I'm doing a lot of data work. I remember when WinForms (which I thought was fine!) was killed. Why they just didn't continue to build on that I don't know (yes, I've heard the explanations, the importance of things like having XML (barf) in the f…

Supposedly is being worked on for making it more Native AOT friendly.

How we got into this mess? WinDev and DevDiv politcs.

After the Longhorn debacle, its technologies landed on DevDiv, like WCF and WPF.

Sinofsky and friends never were that keen in having .NET coming into their turf, it is no surprise that Hilo sample for Windows 7, then praises COM and C++ for Windows applications[0][1].

Then coming in this path, WinRT came to be, with roots as how .NET was being designed, before Microsoft decided to pivot it as another Java like technology[2].

A bunch of folks in WinDev, weren't happy with C++/CX, so they united to replace it with C++/WinRT, because extensions, when clang and GCC are full of extensions, promised to give back a C++/CX like developer experience in 2017[3], never delivered, went to have fun with Rust/WinRT.

Now C++/WinRT is in maintenance mode[4], and Rust/WinRT never took off, and is now Rust/windows-rs[5].

As paying customer, impacted by those childish attitudes, I would have had the whole team fired.

Finally, check the amount of bugs and complaints on their respective repos,

https://github.com/microsoft/microsoft-ui-xaml https://github.com/microsoft/WindowsAppSDK https://github.com/microsoft/cppwinrt/

And then compare with Project Reunion vision from 2021, and where we are three years later

https://blogs.windows.com/windowsdeveloper/2021/03/29/announ...

Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are.

This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is.

[0] - https://devblogs.microsoft.com/cppblog/announcing-hilo/ [1] - https://learn.microsoft.com/en-us/previous-versions/msdn10/f... [2] - https://arstechnica.com/features/2012/10/windows-8-and-winrt... [3] - https://www.youtube.com/watch?v=7TdpWB_vRZM&t=2983s [4] - https://github.com/microsoft/cppwinrt/issues/1289#issuecomme... [5] - https://github.com/microsoft/windows-rs

Re: Writing GUI apps for Windows is painful

#326

Post by wudangmonk »

wolpoli wrote: post #287

> The result should be a single .exe file with no or minimal dependencies and a size of less than 40MB Computers come with a modern browser now. Instead of a .exe file, could it be, let's say, a single .html file with inlined image/css/javascript?

So much time spent on creating many different web frameworks to try and replicate the snapiness of native applications when the solution was to make native applications use web-tech so that both are equally slow. Mission accomplished! Genius!.

Re: Writing GUI apps for Windows is painful

#328

Post by josefx »

EasyMark wrote: post #228
deutschepost wrote: post #152

Earlier quoted context omitted.

Yes. But the article states that they don’t care about that. They just want a single executable.

I never understood the need for a single executable on windows when folders, zip files, and 100% free installers exist if you don’t like zip files. Also nearly all of the gui kits he’s shooting down have ways to build custom components if that’s what you want to do.

None of these help you if you are dealing with users that move executables for convenient access or think updating the sofware just involves dragging and dropping the new executable into the existing installation folder. Customer support had countless stories like that.

Re: Writing GUI apps for Windows is painful

#329

Post by hoten »

ogoffart wrote: post #38

I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev Can be compiled statically in a single .exe that is smaller than 40M. Has a license that allow proprietary on desktop for free. Has dark/light styles. Even comes with a (work in progress) drag and drop WYSISYG editor.

I've been evaluating GUI frameworks for rewriting the editor of a cross platform (Mac Windows Linux and web) game editor I maintain, and this looks worth a shot, thanks for sharing here!

I want to move away from the ancient allegro GUI we use, and so far have evaluated ImGui, RmlUi, and Qt, but so far not totally sold on anything.

Re: Writing GUI apps for Windows is painful

#330

Post by wordofx »

utensil4778 wrote: post #204
CyberDildonics wrote: post #193

Earlier quoted context omitted.

Where did the idea come from that starting with a 40MB exe is small? That's completely outrageous. You could embed all of python, tk, fltk, wxwidgets and pyqt and still not be close to 40MB. FLTK static binaries start at 100KB, win32 binaries can start at 1KB, Juce is about 2MB. Using GLFW or SDL for an openGL window then using IMGUI would start at a few hundred kilobytes. What are you doing in there that makes your…

Man, as a C# dev, I'd kill for a single exe output. The binary being only 40MB is an absolute fantasy. We have a project at work, it's nothing crazy, mostly shuffling data from one pipe to another, maybe a few thousand lines of code. A true standalone build including dotnet is over 180MB. The build that relies on the system dotnet install is still over 50MB. It's not even a GUI, it's a background service. Things on W…

You already have that as a .net dev.

I deploy my asp.net site to Linux by building it as a self contained single file. Deploy services. Have a couple of WPF apps both self contained single file.

They all end up around 43-85mb. The services are smaller when trimming is applied at around 30mb.

Not a single project has ended up over 100mb but I can see that happening if you have a ton of nuget packages.

Post reply on HN