Some options for quick scripted application development include the usual dialog/xdialog and bash route. dialog can be built using pdcurses and can work with any backend pdcurses works with. That means you could potentially use it with Wayland/SDL. There are several GTK based dialog-like solutions. The best of those in my opinion is yad ( https://github.com/v1cont/yad ). Works with GTK 3 and is currently supported. Also provides the most options for controls. There are dialog like programs for GUIs like Qt and WxWidgets as well. Some distributions are using TCL/TK for dialogs and scripts. Others are using lua. Python has also become popular of late. Another solution some users are interested in is a hypertext one using HTML/CSS/JavaScript similar to Microsoft's HTAs (hypertext applications). There are some ways to accomplish that like Electron.js and NW.js.
I brought up the web browser because it's probably a good example of a worst case scenario. There are already some Linux distributions and many alternative FLOSS distributions that are having trouble finding and supporting a browser that can handle the majority of the Web 2.0 sites out there. There are two FLTK/webkit browsers, netrider and fifth. I did some patching for netrider and did manage to build it from source. It's not exactly easy to build webkit with all its dependencies from source. Both browsers are using older versions of webkit. While these browsers work better than many independently developed FLOSS browsers that are not Mozilla or webkit based, they have issues with many sites. Also, webkit source code is not exactly the most portable code. I had issues that prevented building just when I changed versions of my gnu compiler so switching from 64 bit to 32 bit if 32 bit is no longer officially supported may not be easy. The option mentioned most often on the suckless.org mailing list is surf which is GTK (now 3) and webkit. The WhatWG group took over managing the web standards from the W3C. W3C was an independent organization that was interested in accessiblity. WhatWG is made up mostly of businesses and organizations that develop browsers. They tend to push the interests of their particular business or organization. They've added standards to support semantic web so web sites will work more effectively on devices/phones with no keyboards. They've added more multimedia support for formats like those used on Google's Youtube so that add ons like Flash are no longer needed. That moves the complexity of video and audio support to the browser. They've added webGL for 3D/VR/AR support. Another new innovation is webrtc which can be used for video conferencing. The FLOSS video conferencing project Jitsi uses webrtc and does not work in browsers unable to support the protocol. Right now, it's pretty much just Google Chrome and Mozilla Firefox that offer it. Even Firefox is having some issues with implementing webrtc although future versions are supposed to support the protocol better. Webkit was developed by Apple, Google and independent FLOSS projects. Google's now working on Blink instead of webkit and many projects including Qt are using it. Google is also investigating writing browsers using Go instead of C/C++. Mozilla is looking into moving from C/C++ to Rust. There are large companies or organizations behind popular web browser designs. Unfortunately, it's getting to be too complex for someone to attempt to build a browser from scratch and support all the web protocols and Web 2.0 features that are expected to make many web sites work today. Most browser projects adopt one of the large browser engines and use that. Even Microsoft went that route with Edge. If the adopted engine doesn't support the platform you're on, it can be very difficult to port and maintain. This could be a serious problem if 32 bit support is dropped. Main issues with porting from 64 bit code to 32 bit are when a program or library uses assembly and when the program makes assumptions about the size of variables/types. A program or library designed for speed and efficiency might use assembly to improve performance. As I mentioned, I don't usually like to design for efficiency and it's often at odds with portability. I was unable to compile one of the audio libraries I use for a 32 bit Android system because the file handling (off_t) was expected to support 64 bits. The library would have to be rewritten to work properly on that system. Sincerely, Laura -- Mailing list: https://launchpad.net/~torios Post to : torios@lists.launchpad.net Unsubscribe : https://launchpad.net/~torios More help : https://help.launchpad.net/ListHelp
