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

141–150 of 577 posts

Re: Writing GUI apps for Windows is painful

#141

Post by bonzini »

Jare wrote: post #124
bonzini wrote: post #74

Earlier quoted context omitted.

IIRC WinG was basically a way to set up a GDI device context that corresponded to a frame buffer, so you could take your DOS SuperVGA code and run it under Windows, only redoing sound and input. It's been almost 30 years though. :)

That's what it was, mostly. You could do pretty decent games using GDI as long as you just wanted to blit some sprites and were very much adhering to what GDI would give you. If I remember correctly, all the examples in the "GameSDK sampler CD-ROM" (the original name of DirectX 1.0) were in fact not done with GameSDK or even with WinG, but straight GDI.

I think it was better and easier to set up a DIB, treat it as a double buffer of sorts and only use GDI to BitBlt it to screen.

Don't ask me how you do that, though it probably would not take me too much to page that stuff back into my brain by looking at the Microsoft Win32 manuals. Maybe CreateDIBSection? I still remember my kernel32.dll, but not GDI or User.

Anyway, what WinG did (and all it did) was speeding up the blitting part.

Re: Writing GUI apps for Windows is painful

#142

Post by Dwedit »

beart wrote: post #27

Writing GUI apps is painful everywhere, and has been for years. I remember the half-baked transition from Windows Forms to WPF, which was then taken-over by the Windows Phone initiative, which was also extremely painful and half-baked. There's a reason electron is so popular, despite all the complaints about it as a platform. Don't blame the electron devs, blame Microsoft for completely failing to support their own p…

Windows Forms (C#) is basically a continuation of Visual Basic, it's not very painful at all. The only painful bits are when you need to lock a bitmap and deal with raw pointers, and you need to use the "unsafe" keyword.

Re: Writing GUI apps for Windows is painful

#143

Post by troupo »

userbinator wrote: post #85

Problem: It is extremely hard to stylize native Win32 controls. That's not a problem, it's a feature. I am absolutely bloody sick of apps that go out of their way to reinvent the standard UI controls in perplexing ways and behave unexpectedly. Following the system UI preferences is what you should do, and it irritates your users if you don't. There is a “hidden” dark mode for Win32 controls used by Windows File Explo…

I don't know what the situation is right now, but for the longest time ever standard win32 controls where even less useful and more anemic than even the standard web controls. There was always a disparity between what the OS gave you and what the actual good controls MS Office team would think of (until ribbon, but the original ribbon actually did have a lot of thought put into it).

Re: Writing GUI apps for Windows is painful

#144

Post by dang »

Klonoar wrote: post #81
bnolsen wrote: post #58

Earlier quoted context omitted.

[flagged]

[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, though, would be to supply some specific information.

Re: Writing GUI apps for Windows is painful

#146

Post by mrpippy »

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…

Correct. For Win32 apps, the only official support for dark mode is some WinRT APIs to tell if it’s enabled, so you can “adjust your application's painting and rendering code to use a Dark mode color set”

https://learn.microsoft.com/en-us/windows/apps/desktop/moder...

Re: Writing GUI apps for Windows is painful

#147

Post by cxr »

mjevans wrote: post #24

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. It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center. A simple Hello World, click OK to exit the program application should be able to be cr…

> 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 Linux Desktop. Especially when there was a major infusion of interest circa 2010 of folks adopting the MacBook Pro as the developer machine of choice.

I think it's still doable. And I mean down to looks, too, and not just API feel. Aqua from the same time period (Snow Leopard through Mountain Lion era) is the closest thing I can think of to timeless visual design.

It's true that if everyone just made Cocoa apps that looked like they were created with Mac OS in mind it would look out of place on Windows and elsewhere, but (a) it would still look rather good, and (b) it would not look any more out of place than anything else, including Electron and even lots of "native" apps, due to the proliferation of toolkits described in the article not to mention the Gnome identity crisis that has only just recently begun to get reigned in—mostly by following Mac OS cues and being more consistent than before. It's just a shame that it stops at the surface level and doesn't carry over into the actual APIs. Plus those cues are from the post-flattening of UI.

Re: Writing GUI apps for Windows is painful

#148

Post by c-smile »

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.

1. These wrappers are Open Source.

2. I do not have customers that requested either one of these wrappers.

3. Customers that do use one of wrappers, as AdGuard for example, maintain their own version of Sciter/Go: https://github.com/AdguardTeam/go-sciter

Re: Writing GUI apps for Windows is painful

#149

Post by Hamuko »

jwells89 wrote: post #129
hobs wrote: post #116

Earlier quoted context omitted.

It's funny that you mentioned apple because their system shortcuts are integrated as hell and they even let you map them in the OS -> App level, way better than anything MS has ever shipped.

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…

Annoyingly enough you don't really all keyboard shortcuts out of the box even if you build natively. If you create a Button(role: .destructive).keyboardShortcut(.defaultAction) in a SwiftUI dialog, you don't get Cmd+D as the shortcut even though Finder (and I think other apps too) uses Cmd+D as the keyboard shortcut for destructive confirmation dialogs. Thankfully at least a Button without destructive role will get Enter as its keyboard shortcut in the same context.

Re: Writing GUI apps for Windows is painful

#150

Post by jenscow »

userbinator wrote: post #110
crazygringo wrote: post #95

Earlier quoted context omitted.

As a non-Windows user, I'm confused, maybe you can clarify: > If you use the regular Win32 controls then they will automatically get the styling the user has set. Does that mean they'll get dark mode if the system is in dark mode? In which case I don't understand what the author is complaining about. Sounds like dark mode would be working as intended. They want "easy styling" but I took that to mean things like icons…

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

Those colour settings are not aware of Windows 11's "Dark mode"
Post reply on HN