It’s unfortunate slack is this difficult to integrate with. Jabber or IRC clients could be spun up with zero pain.
A streaming; normalizing XML parser doesn't sound like a lot of fun to implement in C89 to me :)
Building a new Windows 3.1 app in 2019: A Slack Client
91–100 of 248 posts
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#92Do the public slack APIs offer enough to built a third party client?
I felt it was enough for me. :)
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#93> Windows 10 [...] cannot directly talk to the ancient SMB protocol used by WFW 3.11.
Not true, you can downgrade the SMB version requirement in the Windows 10 registry.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#94Do the public slack APIs offer enough to built a third party client?
Yes, it does!
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#95Earlier quoted context omitted.
There is no direct correlation between the size of an executable (64kb) and the size of the RAM usage (can be hundreds of MB). I could not find any information about the total memory usage of the application, is it described anywhere?
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.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#96I 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…
Did you get to work with a co-operative task scheduling? This version of Windows still used one I think. What's your experience if so?
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#97Earlier quoted context omitted.
There is no direct correlation between the size of an executable (64kb) and the size of the RAM usage (can be hundreds of MB). I could not find any information about the total memory usage of the application, is it described anywhere?
Win 3.1 apps can also access memory in 64K segments which I only use 1 to hold the humongous HTTP+JSON reply from Slack. Wikipedia says "However, no single process can use more than 16 MB.". Not sure where is the source of that though. https://en.wikipedia.org/wiki/Windows_3.1x
[deleted]
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#98Earlier quoted context omitted.
> 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. If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface? No…
It's Beeware. https://beeware.org/ > Write your apps in Python and release them on iOS, Android, Windows, MacOS, Linux, Web, and tvOS using rich, native user interfaces. Multiple apps, one codebase, with a fully native user experience on every platform.
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.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#99Earlier quoted context omitted.
> 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. If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface? No…
Windows 3.1 apps are somewhat cross-platform because they can be run with Wine on Linux.
It's even better: 64-bit Windows doesn't support 16-bit Win 3.1 apps anymore, but you can still run them via Wine on the Linux subsystem.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#100Earlier quoted context omitted.
Qt and to some extent GTK+ come close. GTK+ can be programmed in Vala which is a fine language that transpiles to C and supports idioms such as asynchronous programming.
> Qt and to some extent GTK+ come close Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug. I'm proficient in C++ (programming for living since 2000), but I wouldn't pick the language for 2D GUIs in 2019. > GTK+ can be programmed in Vala Picking a non-mainstream languages is risky. Harder to find developers. Way more likely to find bugs in the toolchain and these can e…
You can also write GTK+ in JavaScript for that matter, or Python. Vala is a very underrated language though and it should be very easy for a good JavaScript programmer to pick it up.