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

241–250 of 577 posts

Re: Writing GUI apps for Windows is painful

#241

Post by duckywise »

synergy20 wrote: post #115

write a cross platform GUI is even more painful. It's pretty much either paying for Qt or use the bloated Electron.js. Looks like the latter won the market. I failed to see other practical options, flutter was an option, but its strength is not on desktop so far.

What was your problems when using Flutter for desktop? For me, it's the lack of multi-window support. There's a community solution but it's a bit lacking because it spawns another engine while the upcoming official solution uses single engine.

I personally use it for my desktop apps (cross-platform) and building UI for it is a breeze. Though I forked someone's window styling plugin because it's missing some features I need. A native dev would've done better than me but if it works it works I guess.

If I had to satisfy the requirement in the post though, I'd use enigma protector with to make the app folder into a standalone exe and with compression enabled to make it smaller.

Re: Writing GUI apps for Windows is painful

#242

Post by neonsunset »

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…

This has been solved since .NET 6/7 and the results should pleasantly surprise you:

- https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

- https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...

Alternatively, you could try the following first (use .NET 8 SDK):

    dotnet publish -o out -p:PublishSingleFile=true -p:PublishTrimmed=true
Also, I just tried worker template (it includes generic host, DI, logger, etc.) and it's only 5 MiB when AOT compiled on macOS:

    dotnet new worker --aot
    dotnet publish -o out
Will likely take less on Windows and Linux.

Re: Writing GUI apps for Windows is painful

#243

Post by davidhyde »

CyberDildonics wrote: post #193
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.

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…

OP said less than 40MB. You can build Slint binaries targeting embedded devices. So a few hundred KB for a small application. Still arguably too much space but gui frameworks like slint use a domain specific language that generates more verbose code than what a human would typically write. Probably in the interests of being generic.

Re: Writing GUI apps for Windows is painful

#244

Post by Klonoar »

dang wrote: post #144
Klonoar wrote: post #81

Earlier quoted context omitted.

[flagged]

From https://news.ycombinator.com/newsguidelines.html : " Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." " I realize project != article but the same point applies. Note that if by following that guideline, your comment gets "shortened" to the empty string, the implication would be not to post. More helpful, th…

shrug

I acknowledge your comment, and I'm aware of the guidelines. I'm not the only one who questioned their response, so I don't feel particularly off balance here.

Re: Writing GUI apps for Windows is painful

#245

Post by jen20 »

smackeyacky wrote: post #232
EasyMark wrote: post #227

Earlier quoted context omitted.

If you’re on windows and want a “standard” guy, either use the .net GUI or Qt , if you want completely custom and willing to do the work use QML or ImGui (or variant like eGUI)

Which particular .NET Gui? There is a collection of them: MAUI, WPF, Blazor Hybrid, WinUI. Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.

Probably Windows.Forms unless there’s a REALLY good reason to do anything else.

Re: Writing GUI apps for Windows is painful

#246

Post by pests »

mathverse wrote: post #138
c-smile wrote: post #106

Earlier quoted context omitted.

Sciter's support forum is pretty active : https://sciter.com/forums/ Mr. Yuri (Pravic) has his own agenda these days. As far as I know creation of Go, Rust and Python backends for Sciter was a method for him to determine best frontend technology for his organization. If someone wants to take care about Go, Rust and Python wrappers - let me know.

Ultimately as a user / customer I dont care who maintains the bindings I need to use to achieve my goal.

Might end up being yourself.

Re: Writing GUI apps for Windows is painful

#247

Post by ack_complete »

MikeTV wrote: post #205
ack_complete wrote: post #172

Earlier quoted context omitted.

> Most controls ask their parent what color they should be via a window message. There are a LARGE number of areas where this is not provided, such as the text color of a disabled control or the checkbox area of a checkbox control. Even for the cases where such customization points were provided, many of them were broken when theming was added in Windows XP and in comctl32.dll version 6 in Vista, which ignores some o…

Do you happen to have links to any good documentation/articles on this topic? I'm working on what amounts to a dark theme for Win32 controls and largely making it up as I go along, relying on tidbits and off-hand mentions from defunct blogs.

Afraid not, had to piece together a lot of it myself. There are lots of examples available for various components of varying quality -- you'll find some code examples that don't work well with high DPI or all of the sub-modes of a control.

Some controls like buttons, list boxes, list views are reasonably well behaved, especially when theming is turned off. Combo boxes and toolbars are more temperamental. Check boxes, scroll bars, menus, and message boxes require a lot of custom painting work.

Re: Writing GUI apps for Windows is painful

#248

Post by kirubakaran »

Closi wrote: post #15
Aurornis wrote: post #6

Earlier quoted context omitted.

> Today UI apps use 100X more memory, Larger memory footprints aren’t just from the GUI. There is a lot more functionality to deal with everywhere. Just handling modern security, encryption, and certificate checking stack can take up more space than entire executables from the early 90s. I also have literally 100X more RAM now. > are slower, Im fairly certain everyone who says this has simply forgotten how slow mecha…

I assume OP means slower on like-for-like hardware, rather than slower when run on a PC from the 90s, but to be fair the WinForms/WPF component of old GUI's was very fast even on legacy hardware.

Your profile doesn't list your email, so I'm posting here... is this the paper you were looking for? https://depts.washington.edu/acelab/proj/dollar/index.html Your original post for context: https://news.ycombinator.com/item?id=26152600

Re: Writing GUI apps for Windows is painful

#249

Post by neonsunset »

lowleveldesign wrote: post #123

Apps developed for the modern (open-source) version of .NET may be compiled to a native code (NativeAOT). Some time ago, I tried AOT on a simple WinForms project and it worked. Unfortunately, functions using COM APIs are not yet supported (as they rely on reflection). There is an ongoing effort to fix this problem: https://github.com/dotnet/winforms/issues/4649

COM interop now works on NAOT with source generated COM wrappers: https://learn.microsoft.com/en-us/dotnet/standard/native-int...

(it's unfortunate the milestone is set to future in the linked issue though, which includes the light-up for the feature above)

Re: Writing GUI apps for Windows is painful

#250

Post by ack_complete »

Rohansi wrote: post #131
userbinator wrote: post #110

Earlier quoted context omitted.

They'll get dark, light, rainbow, whatever the user has set. This was a feature since at least Windows 3: https://news.ycombinator.com/item?id=25871787

I don't think this actually reflects the new light/dark mode people are referring to here. It will most likely always be the default theme - light. Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes. You could change some colors in the palette and parts of the UI could end up being difficult or impossible to read. Happens if the app uses a combination of palette…

> Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes.

They already do this. COLOR_3DFACE has gotten brighter with each successive version of Windows and in Windows 11 is #F0F0F0. I've had to fix UIs that became unreadable as a result.

Post reply on HN