hestiaGUI Technical Specification - ZORALab's Hestia

Main Purpose

This package's primary purpose is to facilitate all graphical user interface (GUI) components across different technologies like web, Qt, etc. Each leaf package offers their common data structure for rendering across different GUI outputs. Currently, we're supporting the following outputs:

Web (HTML+CSS)

As A Common Utilities Provider

Since this is a parent package to all GUI component, this package supplies all common utilities that are used across all leaf packages. In any cases, it's rare for you to import this package unless you're a leaf package GUI component designer.

Web HTML+CSS First

While there are various UI systems in the market, ZORALab's Hestia prioritizes Web HTML+CSS first mainly as the world from 2023 are moving towards portable computing devices like phone, tablet, watches, and even AR/VR headsets. To ensure a system is available across each different devices under 1 single design, network-based UI is very important than device-based version.

GUI As An Option

The sole reason GUI is made available are mainly to design an product interface for those users who are not technically backed. Hence, a product MUST be able to perform data processing and exchange while having GUI as an optional interface for asthetics and easy to use purposes.

Capable of Rendering HTML, CSS, and CSS Variables List Outputs Independently

Aligning to ZORALab's Hestia main purpose, all GUI components MUST support Web UI and WASM rendering. Hence, each leaf package is capable of rendering HTML, CSS, and its associated CSS Variables list independently when given the same data structure.

Extended Naming Convention

Aside complying to the naming convention stated in the main spec, hestiaGUI extends from it to include some artistic related aspects. Due to GUI being an artwork as its core, all leaf packages shall lead with the main artist's handle instead of the conventional hestia- prefix. That way, we can automatically credit the designer.

Common Design Practice

Normally, the design direction shall always be as little as dependency as possible. However, for coloring and site-wide control values, it's best to use a -CORE UI component to unify them instead. It's easier to maintain and is easier to manage as well. Each commonly used components only use the following APIs:

ToCSS
ToCSS_VARIABLES
ToJS (If possible, don't use it)

Debugger Design Practice

Normally, the debugger design direction shall always be NO dependency and all settings must be independent / design resistance. The UI shall survive even in brutal design deployment. All CSS variables shall be used inside its elements and are not exported. A common one uses the following APIs:

ToCSS
ToJS (If possible, don't use it)
ToHTML (Generate the HTML codes based on technologies)