ZeroNet GUI is not Usable Without 3D Acceleration

[martinvahi]

Environment:

• ZeroNet version: 0.6.0 (rev. 3146)
• Operating system: Raspbian & openSUSE Linux
• Web browser: Chromium (Google Chrome)
• Tor status: disabled
• Opened port: yes

The problem:

The 3D globe at the zite settings panel
depends on 3D support(probably WebGL), but
the WebGL, GPU support, is not available at all browsers
and that makes the ZeroNet much less portable.

Steps to reproduce:

1. Open the ZeroNet GUI in some non-standard browser, like
   http://www.midori-browser.org/
   or
   https://rekonq.kde.org/
   or
   https://konqueror.org/

2. Try to open the zite settings panel by sliding the zero icon.

Observed Results:

Either the zite does not load at all or the zite loads, but
the settings panel is empty, blank.

Wishes:

The JavaScript of the ZeroNet GUI should first
check, whether 3D/GPU-s are supported and
load the 3D Earth only, if the WebGL/GPU support
is available. If the 3D acceleration is not available,
the classical 2D "World map" with color-coded
height might be used, the way geography related
paper-books used to depict mountain range heights
on maps.

http://vterrain.org/Elevation/NOAA_Globe_680.jpg
(archival copy: https://archive.fo/QFJ6k )

[HelloZeroNet]

Thanks for reporting I just tested Midori 0.5.1 and I can confirm , that the sidebar does works on it, but the problem is no related to WebGL support, because for example it works in Tor browser and enabling WebGL in Midori does not fixes it.

I tried to find what exactly missing for the sidebar, but lack of any web developer tools makes it really hard.

[martinvahi]

I do not know, how exactly You tend/prefer to work with JavaScript code, but
I have some JavaScript experience from AN ERA, WHEN THERE WERE
NO FANCY DEBUGGERS embedded to web browsers, specially the
nasty Microsoft Internet Explorer. To cope with the situation, I came up
with a solution, where I wrapped the bodies of ALL FUNCTIONS of
MY JavaScript LIBRARY into a try-catch clauses and
at the catch side I threw an exception that contained a GUID as part of the
error message. Each error message had its own GUID that was unique
within the whole project.

To the start of the function body I placed tests, input verification,
that can be partly disabled in production, but that thoroughly
CHECKED EVERYTHING that I was able to think of at that code region,
WITHOUT WORRYING ABOUT PERFORMANCE, because
most of the thorough tests were enabled at debug mode only.
Style example:

https://github.com/martinvahi/raudrohi/blob/master/src/devel/raudrohi_lang.js#L321

That way, if the JavaScript crashed or had errors, then
I would have a stack trace of GUIDs at the web browser's
JavaScript console. To work with that "stack trace", I created
a plugin/tool for the KomodoEdit

https://www.activestate.com/komodo-edit

https://github.com/martinvahi/mmmv_devel_tools/tree/master/src/mmmv_devel_tools/GUID_trace/src/JumpGUID/src/IDE_drivers/www_openkomodo_com/v_8_0_0

I don't remember everything exactly any more, but the work
process was that I manually copy-pasted the
"stacktrace" of GUIDS from the JavaScript console of the
web browser to a text file, which was parsed by the KomodEdit
tool/plugin and I was literally able to move up and down within the
stack trace of GUIDs so that at a push of an arrow key or
an arrow key replacement key combination
on my keyboard the "cursor" within the stack of GUIDs moved
and at every move the KomodoEdit opened the file and line
of the development JavaScript file, where the GUID resided.

Basically, the result was that I had an interactive debugger
like experience, except that I was able to move both directions,
forwards and backwards, in stead of single lines my "step size" was
one function and in stead of just seeing the code, I was able
to directly EDIT the DEVELOPMENT SOURCE.

The beauty of such a solution is that if the JavaScript is minimized
or I get a stack trace of GUIDs from the client's computer, then
I can debug and look at the situation at my own computer, calmly,
at my own pace. Another beauty of that solution is that the
solution is totally PROGRAMMING LANGUAGE AGNOSTIC.
If all of my source codes have unique GUIDs at all error messages,
at all projects that I have ever done, then I can create a folder that
contains symbolic links to the source of all of my projects and then
grep the GUID from that folder. The GUIDs are unique without
much effort: I just copy-paste the code/text with some existing GUID
and then run

https://github.com/martinvahi/mmmv_devel_tools/blob/master/src/mmmv_devel_tools/GUID_trace/src/UpGUID/COMMENTS.txt

Again, I have that tool integrated to my IDE scripts/settings, Vim, JetBrains, etc.
So all it takes, if the environment has been properly set up, is one key combination
and the tool updates all GUIDs by using regexes and some other tricks that
are described at:

https://github.com/martinvahi/mmmv_devel_tools/blob/master/src/bonnet/lib/kibuvits_ruby_library/src/include/kibuvits_str.rb#L492

id est using only regex is not safe enough.
Another thing that helps with JavaScript is
some form of JavaScript console. I have used

https://yuilibrary.com/yui/docs/console/

But, of course, it's easy for me to speak here. Actually,
what regards to user interfaces, then I currently do not
have proper, usable, JavaScript code to offer, but
my JavaScript project took place so early that I did not
have the opportunity to download the various fancy
JavaScript widget libraries, so I had to develop my own.
And I did. The code is an old, unusable mess
https://technology.softf1.com/raudrohi/2013/09_04_v_25/
(I have an upgraded, but unfinished, unpublished version @ my computer)
but I did get the architecture right, after a lot of tedious work
and I tried to document it by writing a cleaner version of the ideas to:

https://longterm.softf1.com/specifications/rastclsp_t1/

I'm not aware that any other widget library has that kind of an architecture.
The main benefit of it is that it moves a lot of the code from the
application code to the library(read: reusable) code region and
that a widget is a CONTAINER that does not need a graphical
representation. Widgets MAY have a graphical representation, but
menus might be also sound menus, like the ones at phone services.
That spec is a result of multiple projects. The earliest of them was
not even JavaScript, but one client/paid project that was written in Java.
Well, one way or the other, I currently do not have any code to offer that
works with that spec, but the implementation of that spec, mainly in the
form of my Raudrohi JavaScript library upgrade, is my next step at the
(proper) GUI front.

The reason I write all of that here is to offer You some inspiration.
I've been in trouble with the JavaScript myself and may be at least
some of my old JavaScript development tools and methods will help You.

Thank You for reading my comment.

I believe that this problem of browsers and definitely not ZeroNet
Now almost 2018 and they do not support WebGL
ZeroNet this future, it does not need outdated technology
And accordingly to spend for this time there is no sense, let these obsolete browsers themselves do something for ZeroNet

[martinvahi]

Now almost 2018 and they do not support WebGL

The WebGL depends on GPU, which is accessible to browsers only, if there are

DRIVERS!!!!!!!

available for the GPU on a

GIVEN OPERATING SYSTEM!!!

that has been ported to a

GIVEN HARDWARE!!!!

The rest of the contemplation is about what is the design philosophy of the ZeroNet. For example, one philosophical aspect of the ZeroNet is the choice, whether ZeroNet documents, forums, blogs, should be visible 100 years from now, like the text documents from the 80-ties are readable with year 2017 computers and like HTML-pages from the 90-ties are visible at the

https://archive.org/

or is it OK for the ZeroNet to be like the Java Applets based web pages that are impossible to use/see in 2017, because Java Applets are de facto not supported by 2017 web browsers, despite all the advances in hardware. So far the 3D technologies for the web browsers have a

TRULY BAD TRACK RECORD.

Apart from fancier rendering, the 2017 3D web technologies, the

https://www.x3dom.org/
and the
https://www.khronos.org/webgl/

do not offer absolutely ANYTHING NEW. I have not noticed anything substantial that the Java Applets 3D capabilities or the VRML did not offer. The VRML demonstrated that it is not enough for the technology to be totally open, in a form of an open standard that is supported by MULTIPLE INDEPENDENT COMPANIES. I repeat: an open standard and a multitude of independent money streams from multiple companies DID NOT SAVE THE VRML. The 2017 3D web technologies,

the
https://www.x3dom.org/
and the
https://www.khronos.org/webgl/

compete with each other and they do not have the freelancer based developer community to keep them from the same faith that the VRML had. In another words, money is not going to solve it, money DID NOT SAVE THE VRML, because the availability of money IS ALWAYS TEMPORARY. The moment Google Chrome and Mozilla, which are both corporate projects with HUGE money streams, dump the browser 3D support, just like they both dumped the Java Applets, the WebGL and the x3dom will be in the history trash can, right next to the VRML and the Java Applets and the Microsoft Silverlight and the Adobe Flash. Making 3D acceleration a dependency for the ZeroNet GUI makes the ZeroNet GUI less portable and risks with making the ZeroNet GUI unavailable in the future. Examples of operating systems that do not have a proper set of 3D drivers:

• The OpenSolaris forks: https://wiki.illumos.org/display/illumos/illumos+Home
• https://www.dragonflybsd.org/
• http://www.openbsd.org/
• http://minix3.org/
• Probably also the https://www.haiku-os.org/
• I do not know for sure, but I would not bet that the ReactOS has a proper set of 3D drivers: http://www.reactos.com/
• https://www.gnu.org/s/hurd/hurd.html
• http://www.vitanuova.com/inferno/screenshots.html

An example of hardware that has a thoroughly documented GPU, but lacks proper 3D drivers, is the Raspberry Pi:

http://www.raspberryconnect.com/gamessoftware/item/314-trying_out_opengl_on_raspberry_pi_3

https://www.raspberrypi.org/documentation/hardware/raspberrypi/
(Raspberry Pi 3 GPU is the same as Raspberry Pi B+ GPU)

There are a lot of Raspberry Pi clones, competitors, just like the former IBM PC had clones that ultimately took over the market. Those clones might have very different GPUs and a very varying level of 3D driver support. The most exhaustive list of Raspberry Pi competitors that I'm aware of, is:

https://www.board-db.org/

but some most prominent competitors are:

http://beagleboard.org/
http://www.orangepi.org/
http://www.banana-pi.org/
http://www.marsboard.com/
http://cubieboard.org/
ORDROID: http://www.hardkernel.com/main/main.php
https://www.pine64.org/
https://getchip.com/
RiotBoard: https://www.element14.com/community/community/designcenter/single-board-computers/riotboard

The Raspberry Pi like computers are specially relevant due to the fact that the Intel and AMD have formed a cartel that holds monopoly not by free market rules, but by LAWYERS. The 386 CPU patents have expired, but generally speaking, with a few small exceptions like the Via Technologies, nobody is allowed to create or even emulate x86 CPUs, although, Microsoft with its cloud services probably gives it a try:

https://www.theregister.co.uk/2017/06/09/intel_sends_arm_a_shot_across_bow/
(archival copy: https://archive.is/chFKb )

Not only does the Intel-AMD cartel have a lawyers based monopoly, but, as with all monopolistic vendors, they do not work on the quality of their products, preferring cutting production costs to doing a proper job. In the case of the Intel and AMD the quality problems are in the form of security problems, which are partly described at the links of my forum post at

https://groups.google.com/forum/#!topic/minix3/WhTHQX6f9VM
(archival copy: https://archive.is/q06qT )

That is to say, the Raspberry Pi like computers ARE VERY IMPORTANT COMPETITORS that MUST BE SUPPORTED and as long as there is no "generic 3D hardware" interface, like there is "generic VGA hardware" interface, the Raspberry Pi like computers will probably lack proper 3D support even if they have openly and properly documented GPUs.

Thank You for reading my post.