Open martinvahi opened 6 years ago
HelloZeroNet
commented
6 years ago 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
commented
6 years ago 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
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
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:
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.
ghost
commented
6 years ago 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
commented
6 years ago 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
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:
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:
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.
Environment:
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:
Open the ZeroNet GUI in some non-standard browser, like http://www.midori-browser.org/ or https://rekonq.kde.org/ or https://konqueror.org/
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 )