Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a new Windows 3.1 app in 2019: A Slack Client

yeokhengmeng.com

Post reply on HN
Print view View original

181–190 of 248 posts

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#181

Post by gattilorenz »

bluedino wrote: post #131
gattilorenz wrote: post #98

Earlier quoted context omitted.

This sounds great, but it seems there's no out-of-the-box support for a rich text textbox? I have a python script that I want to deploy as self-contained app for windows and osx with a gui. Finding a framework that works, is decent to use, doesn't need hundreds of MBs of dependencies, and has rich text support is...not easy.

In the old days, you would just go on AOL's Windows programming section, find a shareware rich text control, and use that.

In the old days, I would do it in Delphi and have the controls already in my toolbox :)

I was actually thinking of giving it a go, but the idea of a Python backend and a Delphi frontend is as attractive as recoding everything in ASM.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#182

Post by asveikau »

asveikau wrote: post #18

This presents c89 as the most antiquated thing in the world, but VS didn't support mixed declarations and code in a .c file until 2015. There is still a lot of code out there that avoids this to be able to work with MS's compilers.

Shortly after my comment I remembered that even in c99 or c++, there are patterns where mixed declaration and code are messy. WndProc switch statements is one example. You can't jump past a declaration of the same scope, so a case label can't declare anything unless you add curly braces.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#183

Post by asveikau »

barrkel wrote: post #34
asveikau wrote: post #18

This presents c89 as the most antiquated thing in the world, but VS didn't support mixed declarations and code in a .c file until 2015. There is still a lot of code out there that avoids this to be able to work with MS's compilers.

Could have done it with C++, would have worked for calling WinAPI too.

If there are gripes about c89 I don't want to think about how different c++ support would be relative to the late 90s or early to mid 2000s, let alone now.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#184

Post by gattilorenz »

zoom6628 wrote: post #111
gattilorenz wrote: post #98

Earlier quoted context omitted.

This sounds great, but it seems there's no out-of-the-box support for a rich text textbox? I have a python script that I want to deploy as self-contained app for windows and osx with a gui. Finding a framework that works, is decent to use, doesn't need hundreds of MBs of dependencies, and has rich text support is...not easy.

Have a look at nuitka for compiling your script to a binary.

Thanks, I'll try it! I was using pyinstaller atm.

I'm still trying to figure out if there's a GUI that supports different text with mixed colors and features out of the box, and that's not horribly broken in OS X

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#185

Post by zanderz »

tomjen3 wrote: post #44
userbinator wrote: post #42

Notice the binary size of the app is only 64KiB. 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 ;-) 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…

I can't help but agree with you. Honestly I think it went to hell when we decided that it was acceptable to call an electron app native, but that may have been a symptom, not a cause.

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. 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.

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.

These trends seem to be driven partly by conventional wisdom about the lowest common denominator among young people in the workforce, e.g. 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. Or maybe something like QT will win and native code will become a first class citizen again with secondary support inside browsers via WebAssembly?

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#186

Post by laurent123456 »

BubRoss wrote: post #177
laurent123456 wrote: post #162

Earlier quoted context omitted.

It's weird to assume that developers who use Electron do so because they are ignorant, incompetent and lazy. The truth is, everybody knows about Qt, GTK and so on, and everybody knows Electron is heavy but you have to be realistic. As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time, or do you go for the solution which, while not ideal, allows you to deve…

> It's weird to assume that developers who use Electron do so because they are ignorant, incompetent and lazy. I don't think I said all that > As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time, This I think is a big assumption. Making a GUI isn't really that difficult. Most of the time in a program doesn't go into making the actual UI. I never hear some…

> I don't think I said all that

Kind of: "inexperience", "lack of research", "don't want to learn C++"

> Making a GUI isn't really that difficult.

Also a big assumption, especially for cross-platform GUIs.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#187

Post by danShumway »

shakna wrote: post #58
marton78 wrote: post #51

Earlier quoted context omitted.

That's cross platform for Windows, Mac and Linux, but what about Web, Android and iOS?

Ignoring that you probably _don't_ want the same interface across all of those... Qt, as well as Windows, macOS and Linux actually can do Android [0] and iOS [1], and Web is halfway there [2]. [0] https://doc.qt.io/qt-5/android.html [1] https://doc.qt.io/qt-5/ios.html [2] https://wiki.qt.io/Qt_for_WebAssembly

I just want to step in quick to advocate. Please do not use Qt for the web. Their web export tools aren't just unfinished, they're actively hostile to web paradigms. The finished product doesn't render to the DOM, it's completely screenreader inaccessible, it overrides browser preferences. In a lot of ways, Qt on the web is even worse than Flash was.

You know all of the arguments against Electron that people trot out about how it's not real native, and it doesn't follow the right UX conventions or paradigms? Qt on the web is exactly like Electron on native, except way worse and without any sign that it's going to improve, because fundamentally Qt is structured around the idea that it should be able to spit out a binary blob of pixels instead of hooking into web-native primitives like the DOM.

Look into something that's showing more promise, like .NET and Razor. The Rust community is also doing some good work here, although I don't know that they have any UI frameworks that are mature enough to be reliable in an enterprise setting.

These aren't true cross-platform efforts yet, since they're still forcing you to think about HTML. But if I was going to bet on any project ending up with a real cross-platform solution that felt good on the web, some kind of export option from an Open Source Windows Forms or similar is probably what I would bet on. Either Microsoft or (possibly) the Rust community are the two parties that I think are most likely to end up producing a true native UI toolkit that can actually export to the web in a usable, acceptable way.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#188

Post by jcelerier »

DaiPlusPlus wrote: post #71
tomjen3 wrote: post #44

Earlier quoted context omitted.

I can't help but agree with you. Honestly I think it went to hell when we decided that it was acceptable to call an electron app native, but that may have been a symptom, not a cause.

Before Electron people had the arguments about bloated apps when it came to WPF and Qt. And Java apps, like WPF (and most Qt apps I’ve used lately) lacks true integration with native OS widgets so as a user I get an uncanny-valley feeling. At least with Electron you’re essentially forced to style everything - and ever since Windows 8 (or Windows Vista) Microsoft has been actively uglifying native widgets.

> Before Electron people had the arguments about bloated apps when it came to WPF and Qt.

which is funny when you see that Qt runs on microcontrollers now.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#189

Post by ralphc »

yeokm1 wrote: post #2

I built a Win 3.1 app during a company hackathon just for fun. Here, I detail learnings and process for how a new old app can be created with the aid of modern tools and hindsight of old technologies. And perhaps what lessons can it offer us today. Without the benefit of modern libraries and languages, I had to read up and take care of many low level details, socket programming, HTTP, JSON parsing, UI design in code…

I'm one of the "programmers of yesteryear", part-time in the early '80s on CP/M them on to Windows 3.1 after graduation in 1984.

Doing things the old-fashioned way was harder but less was expected of you, time-wise. Getting a "database" (a set of BTrieve files, usually) set up would take days, editing on floppies, etc. It was just expected that making software was a long process.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#190

Post by cwyers »

StavrosK wrote: post #95
amiga-workbench wrote: post #84

Earlier quoted context omitted.

Its running on a ThinkPad 390e, 64mb as standard, and tops out at 256mb, so there is your upper bound. Even at an absolute worst case it still beats the pants off Slack.

And is probably quite a bit faster, too.

It's also lacking so many features as to be unusable.
Post reply on HN