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

541–550 of 577 posts

Re: Writing GUI apps for Windows is painful

#541

Post by jimbobthrowawy »

hobs wrote: post #196
jwells89 wrote: post #129

Earlier quoted context omitted.

Yep, among other things both Apple-unique and emacs-esque text navigation shortcuts are in every native textfield across all apps and anything that's a menu item in any app can have its shortcut key rebound in System Settings without any extra work on the part of third-party devs. It's one of the reasons why longtime Mac users are disinclined towards non-native apps. Most don't bother to reproduce these behaviors, an…

Don't forget you can type any of those menu items in the help dialog and it will not only tell you where it is, and not only let you activate it, it will helpfully show you the deeply nested set of submenus required to activate it. Oh and of course those shortcuts are activateable by other applications to simplify app integration.

I sorely miss that menu search feature from macOS, even though it was unity's HUD on ubuntu that got me used to it in the first place. It's a shame it didn't become a more common feature, especially for programs with hundreds of options in the menu bar.

Re: Writing GUI apps for Windows is painful

#542

Post by saagarjha »

alok-g wrote: post #410
singpolyma3 wrote: post #209

Earlier quoted context omitted.

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.

I mean, if you're willing to do that why not just dynamically link?

Re: Writing GUI apps for Windows is painful

#543

Post by fuzztester »

fuzztester wrote: post #277
dokka wrote: 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?

Thanks, guys.

Re: Writing GUI apps for Windows is painful

#544

Post by rlinge »

rfoo wrote: post #343
beagle3 wrote: post #334

Earlier quoted context omitted.

This comment makes me feel like I live on a different planet. In 1999, I built a completely custom Win32 GUI for a (brandable) chat application - that was the product the company I worked for was selling. Pure C and C++. It was a 32-bit app, not 64 bits. And we felt bad for it being 250KB single executable (skin included in resource section) and not “150KB or less” as was our initial target. But making it accessible…

> but 40MB. Oh man. It is perfectly fine to build a 150KB or less executable today. But then OP decided they don't want to write paint functions for custom GUI and insist on finding a library to do so, I guess that's not what you did in 1999, right?

There's another way to build a 150KB or less executable today. Mime is less than 90KB, have a look at https://webd.cf/webd/ It's a web file manager.

Re: Writing GUI apps for Windows is painful

#545

Post by kalleboo »

bux93 wrote: post #451
zigzag312 wrote: post #403

Earlier quoted context omitted.

> 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, li…

How would you know inconsistency among websites isn't inhibiting users from using them? There's not a Web A and Web B to do A/B testing on. Roundness of buttons? Buttons shouldn't be round in the first place. Back in the day, they were these rectangular things with a shadow and a highlight. You could instantly things you can and cannot click on. Now, it's anyone's guess. Do people click on the wrong stuff? Do people…

> Buttons shouldn't be round in the first place. Back in the day, they were these rectangular things with a shadow and a highlight

I dunno, looks round enough to me https://upload.wikimedia.org/wikipedia/vi/4/4e/Windows1.0.pn...

Re: Writing GUI apps for Windows is painful

#546

Post by bowsamic »

webworker wrote: post #536
bowsamic wrote: post #93

Earlier quoted context omitted.

> Writing GUI apps is painful everywhere, and has been for years. I think UIKit and SwiftUI (and to a lesser extent Appkit) are great

Oddly AppKit seems to be one of the most stable desktop frameworks I have worked with. They've made breaking changes, sure, but they haven't been rewriting, and rewriting, and rewriting the same stuff for the last decade and a half. The situation on Windows these days feels like... cognitive dissonance. If given a Windows app assignment today, I'd pick WinForms if less complicated, WPF if a larger project.

AppKit is very stable yes but it shows its age a little more than UIKit. As you say still better than anything Microsoft can offer

Re: Writing GUI apps for Windows is painful

#547

Post by stinos »

Const-me wrote: post #125

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more. If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your…

I do not recommend C++ CLI.

Can you elaborate on why?

I looked at various ways for interop between C# and C++ over the years, and overall found C++/CLI to be the best overall for our particular application types: it's a separate layer bewteen a C++ backend (which is also used in other non-gui applications), with a windows-only WPF desktop application on top. Mainly because the C++/CLI code itself is simple, readable and fairly effortless to write and maintain. A bit repetitive at times though, but that's going to be the case for any such layer AFAIK. Integration on the C# is seamless, with code completion etc, and C# interfaces can be implemented in C++/CLI directly for instance. The initial setup takes some work but with conversion between common types implemented (ability to e.g. IEnumerable std::vector or std::iterator etc) it's all pleasant and good.

or check this library of mine https://github.com/Const-me/ComLightInterop/

Gotta say this looks neat, but it's exactly the type of code I'd rather not write: UUIDs, bunch of macros, unclear mapping between return types (HRESULT vs bool), having to declare same interfaces both in C++ and C#, ...

Re: Writing GUI apps for Windows is painful

#548

Post by mike_hearn »

fleabitdev wrote: post #217
mike_hearn wrote: post #166

Earlier quoted context omitted.

The issue is the React paradigm, which is a bit questionable to begin with. It's a sort of fake OOP in a trenchcoat pretending to be something else, whilst abusing the language in ways that requires compiler plugins. My experiences with Compose and SwiftUI have been ... not that great. I kinda wish people would just have kept investing in their OOP toolkits.

You're right that reactive UI is a poor fit for most languages (especially JavaScript!), but I think the problem is more general than that. Good UI architecture needs some convenient and efficient way to propagate state changes between different parts of the UI framework [0]. This requirement sits in an awkward place, halfway between imperative programming and functional programming. It just isn't in the day-to-day v…

Yes you're absolutely right that these language dialects keep emerging because regular languages don't have quite the right features for reactive computations. Still, OOP was originally designed for GUIs and is a great fit for that, it's easier to build functional stuff on top than the other way around (apparently, judging from experience of having used both).

The closest I found to what I mean is that JavaFX has a whole observables framework, and there's ReactFX that builds a lot of stuff on top of it. With a small change that I prototyped in the past you can do what React Compiler is trying to do, where you run code and record what properties are read then register dependencies and re-run on change. It's quite a natural fit.

Re: Writing GUI apps for Windows is painful

#549

Post by boffinAudio »

neonsunset wrote: post #380
boffinAudio wrote: post #335

I just write GUI's in tkinter (python), build a single .exe with nuitka, and interface with generalized application functionality either as a .dll or python module .. tkinter may not be the sexiest way to do things, but its definitely productive in terms of the code-compile-distribute methodology, and it is very easy to wire up to a generalized 'daemon'-style abstraction, where the app logic is implemented as a daemo…

Oh god, seeing TkInter applications, and inevitably, having to fix them particularly on macOS just fills me with rage. Whoever reads this - do not use TkInter.

Whats wrong with tkinter? You're negative experience can't possibly be the standard by which 15+ years of productive use of it is to be discarded .. perhaps you haven't learned how to make beautiful UI's with it, but some of us have ..

You can easily go from Figma -> tkInter code -> app, too.

Re: Writing GUI apps for Windows is painful

#550

Post by throwaway2037 »

ack_complete wrote: post #357
throwaway2037 wrote: post #293

Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as: > Writing GUI apps for Windows is painful when requirements are unrealistic They should try to target .NET Framework 3.5 using WinForms. That is my best suggestion, as all recent versions of Windows will have this installed (at least).

.NET Framework 3.5 is no longer installed by default starting with Windows 10.

The reason why I suggested 3.5 was to include a long line of compatibility with older versions of Windows. And, correct me if wrong, a binary compiled with / targeting 3.5 will still run on 4.8
Post reply on HN