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

401–410 of 577 posts

Re: Writing GUI apps for Windows is painful

#401

Post by EvanAnderson »

zigzag312 wrote: post #394
EvanAnderson wrote: post #101

Earlier quoted context omitted.

> That's not a problem, it's a feature. 1000 times this. I want software I'm running to look like the rest of the OS (and every other application) and respect my OS-level UI preferences. In the case of Win32 using the OS primitive controls mean that your application gets tons of accessibility and preference features "for free" (albeit Microsoft has done a good job in later Windows releases of removing the functionali…

> I want software I'm running to look like the rest of the OS This is an impossible task on Windows, as it has multiple, inconsistent UIs by itself.

I want the apps I run on Windows to look like other Win32 apps. I want them to use native Windows controls.

All the UI "enhancements" in Windows 8 and subsequent versions are garbage and irritate me just as much as any other non-Win32 native UI.

Re: Writing GUI apps for Windows is painful

#403

Post by zigzag312 »

ZoomZoomZoom wrote: post #186

> uses native Win32 components and offers no styling options It's a feature. Custom styling should be considered a hostile pattern in most cases, except in highly specialized software with workflows dependent on prior user experience, such as DAWs.

> Custom styling should be considered a hostile pattern in most cases

Why? Almost every website has custom styling and yet it doesn't seem to inhibit users from using them.

Good UI/UX patterns seems to be universal. As consistency is part of good UI/UX there are things that should be consistent with the underlying platform. But consistency with the platform is not equally important for all things. For some things, like window management, it's much more crucial, that it is for other things, like roundness of buttons.

> except in highly specialized software with workflows dependent on prior user experience, such as DAWs

It's not just about prior user experience. If a custom control enhances UX for a specialized task, it has a good reason to break some of the consistency. All specialized software (DAWs, graphics applications, IDEs etc.) have such features. Limiting themselves to just native components would lead to a suboptimal user experience.

Re: Writing GUI apps for Windows is painful

#404

Post by biztos »

cageface wrote: post #386
biztos wrote: post #372

Earlier quoted context omitted.

I don’t have much app experience, I’m mostly a back-end guy trying to build some prototypes and (hopefully) one product. I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony. For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind…

If you really want native look and feel then really your only choice is to use the native toolkits. I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now. I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overa…

Thanks, I will have a look at that. Serendipitously, I'm in the market for a new music player!

Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.

Re: Writing GUI apps for Windows is painful

#405

Post by eptcyka »

kelnos wrote: post #309
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.

Agreed. Also didn't get why he felt complying with the terms of the LGPL for a statically-linked .exe would be so much of a problem. Just put the object files and build script in a zip file, and upload it to the same webserver where you plan to put the program. Add a line in the "About" dialog (or whatever) pointing to it. Done.

Whilst I don't understand the users who are hell bent on having a single-executable work, if you have users who are hell bent on using but a single executable, you have to meet them where they're at.

Re: Writing GUI apps for Windows is painful

#406

Post by torstenvl »

mjevans wrote: post #296
torstenvl wrote: post #62

Earlier quoted context omitted.

This exists. It's called wxWidgets. It's an API shim over native components plus some convenience classes for abstracting out OS-specific functionality. It's LGPL with static linking exception, so no DLL hell. I'm not quite sure what you mean by open spec, but it's just an API not a protocol, and uhhhh.... https://caselaw.findlaw.com/court/us-supreme-court/18-956.ht...

The library exists, BUT it is NOT shipped natively and NOT (AFAIK) something which trying to run a random downloaded utility app will trigger the system library loader prompting for the 'common wxWidgets runtime, for free, codesigned by Microsoft' download and install from the store to run the app.

Your previous post said

> the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does

If there's no DLL required then why does it matter if the DLL is automatically downloaded from the Microsoft store? DLLs are not useful for statically linked binaries.

Re: Writing GUI apps for Windows is painful

#407

Post by qw »

banish-m4 wrote: post #195

A. If a gun were placed to your head and you had to write a native Windows app, what stack would you use? B. And, if you had to write a cross platform app, which framework would you use?

If money was not an issue, I'd probably try Delphi for both A and B, which can create native cross platform apps.

If not, I'd try Lazarus for A and Kotlin compose for B A: Lazarus or Delphi (if money was not an issue)

B: Kotlin compose or Delphi (

Re: Writing GUI apps for Windows is painful

#408

Post by eXpl0it3r »

ZoomZoomZoom wrote: post #186

> uses native Win32 components and offers no styling options It's a feature. Custom styling should be considered a hostile pattern in most cases, except in highly specialized software with workflows dependent on prior user experience, such as DAWs.

What about a simple dark mode, that even the OS provides options for?

Re: Writing GUI apps for Windows is painful

#409

Post by alok-g »

rty32 wrote: post #278
Aurornis wrote: post #19

This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options. Specifically, the requirement for completely custom GUI styling without writing his own render functions means it’s really a task of selecting easy, customizable GUI libraries rather than generic GUI work. The requirements to be self-contained executables and under a…

Agree. "Single executable" combined with "less than 40mb" is just looking for trouble for what the author is trying to do. If you want to do win32, go ahead and give up styling. Otherwise, make compromises. I think many of these are excellent choices chosen by many programs that I use, it's the author's stringent requirements and unrealistic expectations that is holding back.

Winamp comes to mind as a counter example.

Re: Writing GUI apps for Windows is painful

#410

Post by alok-g »

singpolyma3 wrote: post #209
deutschepost wrote: post #73

Earlier quoted context omitted.

LGPL. Which eliminates his requirement for a single executable. With LGPL you are only allowed to link dynamically.

Not true at all. The LGPL does not specify anything about mode of linking or anything like that. What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part. Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done. With norm…

Cool!

Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.

Post reply on HN