←back to thread

Visual Basic 6 IDE recreated in C#

(github.com)
377 points porterde | 5 comments | 14 Nov 24 21:47 UTC | HN request time: 0s | source
Show context
wiseowise ◴[14 Nov 24 22:51 UTC] No.42142078[source]▶
Still don't understand how we went from this to modern GUI toolkits.

It looks and works so intuitively.

replies(14): >>42142147 #>>42142252 #>>42142509 #>>42142582 #>>42142873 #>>42143270 #>>42143473 #>>42145120 #>>42145467 #>>42146571 #>>42147144 #>>42147616 #>>42148647 #>>42155384 #
alkonaut ◴[15 Nov 24 09:02 UTC] No.42145120[source]▶
At the same time it's common to hear "how does this not support high DPI?" or "How does this app not have a dark mode, it's 2024!" etc.

Modern toolkits just do a lot of stuff that older toolkits didn't. Some times at the expense of not being as quick to get off the ground as VB was.

The original winforms implementation in the early 2000's was pretty close to VB in terms of efficiency but its warts were numerous, e.g. the DPI used in the designer view (when writing the code) affected what happens when you run it, and so on.

replies(2): >>42145500 #>>42147171 #
1. liontwist ◴[15 Nov 24 14:18 UTC] No.42147171[source]▶
Dark mode would have been trivial with old toolkits because they used standardize look and feel. In fact motif lets you customize the color scheme through a text file.

Which can make each app fit the appearance of the given desktop.

Old guis also had more accssibility features.

The only thing modern ones have going for them is animation and visual customization.

replies(1): >>42148646 #
2. Kwpolska ◴[15 Nov 24 16:57 UTC] No.42148646[source]▶
Old toolkits make it much easier to set the text color of some label to #444, which looks fine on a light background, but is very hard to read on a black background. Setting it to some well-defined MutedText color requires more effort, and it requires the toolkit vendor to have thought about named colors in the first place (and if there are named colors, they might not be meaningful like Muted or Success, but instead ButtonBackground or TooltipText).
replies(1): >>42150528 #
3. liontwist ◴[15 Nov 24 20:23 UTC] No.42150528[source]▶
You can change background and button colors too.

Other point is noted. But let’s compare the alternative:

1. Fiddle with a config file for each app for a week. Distro includes this in dark mode set. 2. Each app writes custom code to listen for and adapt to dark mode events.

replies(1): >>42155753 #
4. Kwpolska ◴[16 Nov 24 10:51 UTC] No.42155753{3}[source]▶
Let me restate the problem: I set my system-wide window background to black and text color to white. An app developer sets a label to dark gray text and default/transparent background. The end result is that I cannot read the label. Or the developer uses black icons on the toolbar — and I cannot use the toolbar, because I can’t see anything.

macOS introduced system-wide dark mode a few years ago, but app developers had to recompile and opt into it. This was done so that they could adjust their artwork and overridden colors to it. Windows 10 added dark mode, but only for "modern"/UWP apps. Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).

replies(1): >>42156352 #
5. alkonaut ◴[16 Nov 24 13:42 UTC] No.42156352{4}[source]▶
Black-on-black is a big problem. You can't make an app use a dark mode unless it's painstakingly crafted to support it. Only trivial apps would work by changing some system-wide palette. Also, if there is any artwork (button icons etc) then that has to be done in two or more sets, for varying backgrounds. Few icons would work well on both a light and dark background.