torios team mailing list archive

[ml@xxxxxxxxxxxx]

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