I have good experience creating a custom GUI framework for embedded Linux: drm/kms, gles, NanoVG,, everything on top is custom C# code in.
I mostly program for Windows and use C# for the GUI.Ĭross-platform story is complicated, though. Or maybe something like QT will win and native code will become a first class citizen again with secondary support inside browsers via WebAssembly? javascript and html are so much easier, let's build everything on those, and next thing you know those have become a given and the next crop of kids will use something new on top of that. These trends seem to be driven partly by conventional wisdom about the lowest common denominator among young people in the workforce, e.g. Later, at a different job, the UI was Electron based, but designers no longer worked in HTML, they used some other tools and it had become the job of engineers to write the HTML and CSS to match. Designers by the dozens would be hired, then get fed up with these limitations and quit, complaining that they wanted to have the freedom to make UIs in HTML and CSS, and that users are used to interacting with Web UIs so everything should look like that. Some years ago I worked on a very popular Windows desktop C++ program that had to stay small and backwards compatible, which meant only Win32 APIs and homemade libraries. At least you'll save some of those 676 bytes that way. They will paint themselves automatically just like the listboxes that you used for the chat contents and userlist. Like so.Īnother small tip: if you make it a dialog-based application, you won't have to bother with WM_PAINT and drawing text yourself - you can just make the "statusText" and "settingsText" edit controls, and use SetWindowText (or SetDlgItemText) to set their content. Note that C89 only prevents declarations of variables in the middle of a scope you can simply create an inner scope with new variable declarations at its start. Win32 has native TLS support (via SChannel library, not well-documented but examples exist) and you'd be able to even use it practically (32-bit applications will run on all current versions of Windows, both 32 and 64-bit.) I'm a long-time Win32 programmer who started in the tail-end of the Win16 days and one of the things I've wanted to write if I had the time and need was a Win32 native Slack client, to show that it can be done with far less resources, but you've gone even further with Win16. More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most of a modern CPU core to provide its basic functionality. In the demoscene this would be a disqualification as it's 676 bytes over the limit, but in this case I'll overlook it because of the sheer awesomeness of what you've done (and I'm sure trimming off 676 bytes wouldn't be too difficult -) Notice the binary size of the app is only 64KiB.
0 kommentar(er)
