HyperText Desktop Environment
Shell
Latest commit 1f2a7dc Dec 3, 2016 @xoftware committed on GitHub htde.org
Permalink
Failed to load latest commit information.
boot
livesystem
pekwm
src/prototype
zram
CSS.png
HTML.png
King DOM.png
README.md
mount.sh

README.md

HTDE

Desktop = Browser;

#| Project Goals

"The Web Browser makes for the perfect Desktop Interface. That is, after a careful re-design of JS/AJAX/CSS/HTML standards."

Platforms

  • Linux (PekWM)
  • Windows ([Window Manager])
  • Mac ([Window Manager])

Desktop

  • Launch Applications/Shortcuts
  • Custom Interfaces

Omnibar

  • Browse URLs
  • Search Web
  • Search Desktop
  • Run Shell Commands
  • Run Javascript

Context Menu (Right-click)

  • Open Link on New Desktop
  • Open Link on Desktop -> NW, NE, SW, SE

Developer Tools

  • Markdown Parser
  • Benchmarking Suite
  • XUL Fiddle

Filesystem Integration

  • Filesystem Transpiler (Filesystem Heirarchy -> JS Framework)
  • Version Control
  • COW
  • Page Cache

Web Engine

  • Coded in Rust?
  • Optimized and Fixed JS/AJAX/CSS/HTML
  • Selective Rendering (i.e. DOM Diff/IDOM)
  • Hardware Acceleration (GLSL Box-model)
  • Multi-threaded (Concurrent)
  • URL Schemes (ex. htde://)
  • Modular (Events/URL Schemes/XHR Data/CSS Properties/HTML Elements/...)


#| Roadmap

(9/5/2016)

There are two main things on the to do list.

1. URL Scheme API

Experiment with options. Determine best-practices.

  • JavaScript: Generic Request Handler
    • Standards: Intuitive
      • (Doesn't have to follow XHR, but
      • compatible with Servers; XML, Content-Header(s))
  • HTML: Links (HyperText)
  • C++: Modules
    • Data Formats: (JSON, XML)
    • Event Handlers: Low-level System Calls (I/O, RAM, NIC, Shell)

2. CSS Framework

  • Box-Model
    • GPU Acceleration: GLSL Property Definitions
    • Framework: Geometric Subset of 3D
  • Inheritance
    • Render: Optimal Methodology
    • Re-Render

CSS is probably the most important feature of the Browser. This may sound funny! We typically think of CSS as the dissapointingly quirky chore to our development. That's the problem. The CSS framework is flawed, and causes developers to spend inordinate amounts of time memorizing or working around those arbitrary quirks, instead of studying and applying elegant and powerful Computer Science. This very negatively impacts application infrastructure, workflow and life-cycle, and ultimately the host ecosystem. At the end of the day, the Browser is a Layout and Rendering engine. The framework for rendering has to be as effective as possible. HTML provides the tree, but no Element can be rendered without CSS Rules and Properties. Those are what tell it how to, for instance, display: block or display:inline. First of all, for inheritance alone, developing the loop requires an effective methodology. That's one thing. It is another thing when you can apply dynamic functionality to it in real-time. In other words, being able to handle the page with JavaScript triggers re-layout and re-render. Many optimizations can occur, not limited in scope to what we see with Incremental DOM or the DOM-Diff, such as what React championed. Already, as with the Servo/WebRender project, GPU Accelerating the properties with GLSL shows drastic performance increases up to hundreds of FPS. I aim to take it a step further, and define the box-model as a proper 2D geometric subset of a 3D plane, with modular features. The problem today is lack of framework (and obsolete technology). Developers have to wait for new features to be implemented, and just end up with more arbitrary mappings that are still well below par. This is how you solve that problem. Aesthetic features will be appropriated separately from a solid core, which can seamlessly be built outwards and upwards.

Actually, in designing this browswer, I've discovered that anything involving CSS integration turns out to be the most important.

The CSS Rules -> GLSL Modules -> Structural Framework -> Render Methodology are mutually dependent on one another. So they're interdependent. That means carefully balancing the constraints and requirements of each, such as relatively high-level modules, in the sense that they're comfortable to code, with a low-level methodology, in the sense that it is performant. When dealing with things like Trees, Vertex and Matrix Math and Render Methodologies, there's a lot that has been studied and optimized by Mathmeticians and CS for decades. I am willing to trade some performance for intuitive extensibility, as anything properly hardware-accelerated, let alone multi-thereaded, will already be orders of magnitude faster than any legacy code-base browser today, but it's best said like this. I want to get as much performance as possible while still having a robust, modular framework. I know that you can get better performance if you optimize your sandboxed set of arbitrary functionality, and that is exactly what I'm trying to prevent. A site-specific lockdown.

Ultimately, the point of this DOM Engine is to exist as any other 64-bit Library, in this case, a standard UI, with the Box-model as a specific configuration of that. The URL/Scheme Modules will then allow freely coupling it to any back-end, say the Desktop, or even a Video Game.

(9/15/2016)

| Controllers                        | Protocols                    | Methdologies                |
|------------------------------------|------------------------------|-----------------------------|
| Application                        | http://                      | [Contextual Events]         |
| - [Back-End]                       | https://                     | Scoped                      |
| - Desktop Environment              | httptp://                    | - Requests                  |
| - Video Game                       | ftp://                       | - Sockets                   |
| - Server                           |                              | - Frames                    |
|                                    | ws://                        | - State                     |
| Service                            | [WebRTC]                     |                             |
| - [Generic Utility]                | rss://                       | Sequential                  |
| -                                  |                              | - Promises                  |
| -                                  | file://                      |                             |
|                                    | tty1://#                     |                             |
| Resource                           | tty9://$                     |                             |
| - [System Call]                    | cmd1://                      |                             |
| - File System                      | cmd2://                      |                             |
| - Shell/Command Prompt             |                              |                             |
|                                    |                              |                             |

(10/1/2016)

(10/26/2016)

#| Study