231–240 of 248 posts
It’s unfortunate slack is this difficult to integrate with. Jabber or IRC clients could be spun up with zero pain.
Show us :-) I'm sure writing mIrc was not "zero pain" back in the day. And Jabber needs a XML parser which is more complex than a JSON parser.
Aaw cheating with https. I wonder if an embeddable library like BearSSL would be hard to get working.
Something I can try next time! I didn't know about BearSSL before
They needed some way that you could be waiting for either window messages or socket data. Otherwise your window would stop responding to input or repaint itself if some socket operation blocked.
Related: winevdm makes running 16-bit apps on 64-bit Windows possible: https://github.com/otya128/winevdm
Earlier quoted context omitted.
> 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…
> Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug. Have you seen the state of Javascript 'ecosystem' and job market?? Both statements are false. The real reason is that C++ toolkits don't have platform and device independence. HTML and CSS are really good and powerful design tools, especially compared to composing raw pixels like you'd (essentially) be forced to do…
Let me correct: GTK+ is not C++, it's C. Qt is very cross-platform: it supports about 10 platforms, including Linux, Windows, and macOS. You are not doing anything close to compositing raw pixels in Qt or GTK+. They have layout managers that are specifically made for typical application UIs, and they have lots of ready-made widgets. Qt also has QML, which is a declarative UI descriptions language kind of like HTML/CSS but much more productive because (gasp) it's actually designed from the ground up for applications, not websites.
Earlier quoted context omitted.
> But we are finally seeing emergence of desktop applications from major players for Linux because of electron. In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration. If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?
I like the conceptual separation. I like alt-tabbing to "Slack" not "Chrome". It also doesn't have any of the header bar so the electron app has more UX control, including access to OS level window menu options. Also it can do things that you can't do inside the browser. E.g., I've seen electron apps that come with other background processes. I also think it performs better in terms of versioning/caching resources. S…
Earlier quoted context omitted.
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?
Windows (not only the 16-bit 3.x, but going as far as the newest 64-bit ones) uses an event loop for the GUI: your program runs a loop calling the GetMessage function, which blocks until the next window message is available. As long as you don't take too much time processing each window message, you don't have to even think about cooperative task scheduling, since Windows will do it for you while waiting on GetMessag…
You are guaranteed no context switches unless you explicitly request one - did it simplify some parts, or alternatively made it more complex? It's an asynchronous application.
Considering that Windows 3.1 takes less space than Electron binary, one can actually run this program in VM and get better performance and less RAM usage than official app.
I have DOSBOX, but Windows 3.1 runs very slowly on DOSBOX.
It’s unfortunate slack is this difficult to integrate with. Jabber or IRC clients could be spun up with zero pain.
Show us :-) I'm sure writing mIrc was not "zero pain" back in the day. And Jabber needs a XML parser which is more complex than a JSON parser.
Also, an IRC client is a joke, it can be compiled and built even on BSD 4.3, released in late 80's.
The suckless guys created some IRC clients in few lines, and the sj client is not that difficult.
Heck, you could write an IRC client with Bash and even with Netcat/ed.