fundament-software / feathergui

Feather - An Interface For The Future

Feather

Feather is a language-agnostic, universal user interface library.

Building

Feather uses cmake to build, and utilizes nix flakes on NixOS, or the vcpkg build system on all other operating systems.

vcpkg

Feather maintains a fork of vcpkg (this may be turned into an overlay in the future). Clone the git repository from https://github.com/Fundament-Software/vcpkg into a folder with enough space to hold a bunch of compiled binaries, and run bootstrap-vcpkg.bat (for windows) or bootstrap-vcpkg.sh (for other OSes). Once the script completes, run vcpkg install glfw3:x64-windows-static (on windows, start with .\vcpkg.exe) and follow any instructions that pop up.

Next, clone the featherGUI repo, if you haven't already. Inside the root directory of the repo, create a build directory and open it. Inside the empty build directory, run the cmake command that is appropriate for your platform, being sure to replace <ROOT_VCPKG_FOLDER> with the folder you cloned vcpkg into, and adding any additional options you would like.

Windows

cmake .. -DCMAKE_TOOLCHAIN_FILE=<ROOT_VCPKG_FOLDER>\scripts\buildsystems\vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static

If you don't have cmake installed on your system, you can use the version vcpkg installed:

<ROOT_VCPKG_FOLDER>\downloads\tools\cmake-<LATEST_CMAKE_VERSION>-windows\cmake-<LATEST_CMAKE_VERSION>-windows-x86\bin\cmake.exe .. -DCMAKE_TOOLCHAIN_FILE=<ROOT_VCPKG_FOLDER>/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static

Other Platforms

cmake .. -DCMAKE_TOOLCHAIN_FILE=<ROOT_VCPKG_FOLDER>/scripts/buildsystems/vcpkg.cmake

If you don't have cmake installed on your system, you can use the version vcpkg installed:

<ROOT_VCPKG_FOLDER>/downloads/tools/<CMAKE_PATH_FOR_YOUR_PLATFORM>/bin/cmake .. -DCMAKE_TOOLCHAIN_FILE=<ROOT_VCPKG_FOLDER>/scripts/buildsystems/vcpkg.cmake

Nix Flake

Ensure that you have enabled flake support in your configuration.nix file (or equivilent):

nix.package = pkgs.nixFlakes;
nix.extraOptions = ''
  experimental-features = nix-command flakes
'';

Clone the featherGUI repository, if you haven't already, then run nix build inside the root directory.

feathergui's Issues

DirectWrite refuses to give default lineheight

FeatherGUI currently has to guess what the default font lineheight is because DirectWrite, despite clearly having an internal concept of what the default lineheight is, which is used when passing a lineheight of 0, absolutely refuses to tell us what the fucking lineheight actually is. GetLineSpacing() returns 0 when used on either the font or the layout until an estimate is made and assigned to it via SetLineSpacing().

Comprehensive DPI support

FeatherGUI already has basic dpi support, and includes fgMonitor if a given program wants to attempt to conform to a monitor with a different DPI from the root. This DPI is sent down through the FG_DRAW chain, but it's not clear how text and image rendering should respond to it. By default, fgResource simply converts the coordinates into root DPI before passing it in, but this might not be sufficient. For one, text would require an entirely different font for each DPI, because hinting changes cannot be scaled. This would likely have to be captured in a DPI change event of some sort - this could be another FG_MOVE notification, using a subtype of FG_SETDPI, which would make sense.

Furthermore, it is unknown if things like a roundedrect should have DPI-aware corners. If you have a rounded rect with a corner radius of 5, does it stay at 5 pixels or does it get scaled to the DPI? Does it depend on context? Clearly if you intended a rounded rect to have just enough radius to look like a perfect circle, this would have to be scaled appropriately by the DPI, but if you have a subtle 2 pixel curve on a button, this might not necessarily be scaled. While this sounds like a job for some sort of DPI_SCALING flag, it's not clear what would actually be scaled by the dpi flag. Is the outline scaled? Are both the corner radius and the outline scaled at the same time by the same flag? Do they have different flags? Would outline scaling affect lines or are lines always 1 pixel no matter what? Requiring a rendering implemention to support arbitrary thick lines would potentially be a serious issue.

REWRITE IT IN RUST

rewrite the backends in rust because fuck C++ honestly

fgOpenGL should avoid VAOs when not supported

Currently we always use VAOs, which is bad, because they were only introduced in OpenGL 3.0 - instead we should emulate them for OpenGL ES 2.0 (WebGL) and older OpenGL versions.

Linux Backend

Once we have an #29 OpenGL ES 2.0 backend, we need to use this to create a Linux backend that basically just spawns an X window and then draws everything over it. The tricky part of this is writing input processing for Linux.

Ensure pipeline is gamma-correct

The pipeline currently does not enforce gamma-correct resizing. The texture needs to be linearized before the mipmaps are generated and then reconverted back to sRGB after the mipmaps are generated (or simply left linearized).

WebGL backend

Once #29 (the openGL ES 2.0 backend) has been implemented, this should be compile-able to WebGL using Emscripten, with some minor changes to the codebase to properly interface with the WebGL backend. A custom input interface will be necessary to extract as much input as possible from the web browser.

Re-implement all aspects of the smoke test in Scopes

All sections of the smoke test should be recreated in Scopes using after #61 is completed.

• Clearing the background
• Creating and processing a compute shader
• Creating and drawing a rectangle
• Creating and drawing rendertargets
• Creating and using a mesh shader

OpenGL ES 2.0 backend

Once #27 (default text rendering via harfbuzz) is implemented, an OpenGL ES 2.0 backend should be created that works on all known operating systems and environments.

Wide-gamut color spaces

Currently, feathergui simply stores all colors in a standard 32-bit integer. Switching this to a 64-bit integer would allow encoding higher precision color spaces for monitors that support this. The new Android api has specifications for encoding various color spaces inside a 64-bit integer. Because feathergui's fgColor is already defined as a type, it would be fairly trivial to extend the type into a 64-bit integer with functions for converting between color spaces.

For sanity reasons, a "default" color space would need to be chosen as the base representation handed to the backend. This could theoretically be specified by the backend itself, in the same way the backend currently specifies a default text representation.

Implement basic Message Queue

In order to get anywhere, we need to know what our message queue system is going to look like, or at least have some basic version of it, because this is required to implement any sort of backend API. This depends on a programmable switch statement in Terra.

Blocks Unit Testable Backend API

Textbox input formatting and restrictions

Most textboxes have the ability to format or limit what is typed into them. Feathergui's current proposal is seperating formatting and verification operations.

Verification would be a simple regex that must be satisfied in order to accept a new character - pasting text would paste as many characters as possible until the regex is violated. This is simple to implement, but requires a regex library of some sort to be included.

Formatting would use a custom printf-inspired string, such as %2/%2/%2 to signify a date. This means the textbox will accept from 0 to 2 characters before inserting a / character. If two characters are entered and then a / is typed, it simply shifts the input past that character. The textbox should display the expected format via the placeholder text color for text that hasn't been entered yet, with an underscore _ standing in for each expected character. %0: would allow for an infinite number of characters to be input, and would only terminate once a : character was entered. %% would resolve to a single % format character.

It's not entirely clear how much this would affect cursor placement and text insertion. It depends on what kinds of restrictions are placed on cursor placement and text deletion within preformatted strings.

Make sure color pipeline handles colorspaces properly

so like we should be able to choose what colorspace we interpolate in for gradients, texture resizing, etc. because interpolating in linear RGB is just bad a lot of the time even though its better than sRGB

also i wanna support specifying colors in HSLuv https://www.hsluv.org/

Any screenshots, pictures, etc. of existing (demo) apps?

Pictures or it did not happen! 😉

Get rid of GLFW

GLFW breaks several aspects of feather that we want to implement, because it obscures features of the host operating system that we need access to, such as the raw message pump, and the UI sync object. We should implement our own message and input handling code for each platform, although we can use GLFW as a reference if needed.

Colorspace support when loading textures

so like a lot of texture loaders dont respect image colorspace metadata. we should

Build ground-truth software rasterizer for testing

Create a ground-truth software rasterizer that uses maximum precision calculus for all pixels and establishes the baseline target for the compositor.

• Add an image diff option that can be invoked from the build step
• Use a nix derivation that creates a build artifact with a set of example scenes, rendering them with each backend and diffing them with the ground truth image.
• Output statistics of the accuracy % for each test scene and use feather to create a bar graph that is displayed in the git repository.

Stray STRINGIFY() and TXT() macros

feathergui/fgOpenGLDesktopBridge/Bridge.cpp

Line 143 in 7f59b49

#define _STRINGIFY(x) x

Implement Kernels API

[TBD, need architecture overview]

Return detailed errors when possible

emplaceContext/attachContext should return error codes. Error codes for OpenGL should be expanded so they can be logged even if the values are not standardized.

Every possible crash should have a check and be caught. All errors should be logged appropriately before returning. There are some sections of fgOpenGL where this doesn't happen (we assume all functions are valid which is not true) and fgGLFW plus the desktop bridge do not have robust error returns like fgOpenGL, so must manually enforce proper logging of all possible errors.

Improve JSON implementation

• expand the tests to ensure that it works properly on a wider variety of json inputs
• take care of the couple features that were not implemented
• replace the use of cjson with an implementation in scopes that ensures type safety/memory safety

Arbitrary Alpha-Channel Masking

One of the requirements of Material Design is for certain animations or effects to be clipped precisely to a control, and a control could be multiple objects (like two rounded rectangles perpendicular to each other in a cross formation), which is impossible to write a general clip for. This needs to be solved using some sort of masking layer, potentially in combination with the layers introduced in #17 for rotational clipping support. This would function by simply setting the alpha channel of the layer to the inversion of the mask and then drawing things on it with the appropriate blend options.

Unit Testable Backend API

The Backend API needs to be tweaked so that it is unit-testable, but this requires implementing #36 the basic message queue first. These unit tests should be able to spawn a window and create a basic drawing of a rounded rectangle with text on it, and should respond to that rectangle being clicked (by processing the raw inputs, not actually implementing any UI logic). This ensures the backend acts as a sane abstraction layer for the OS level drawing and input functions.

Finish wrapping backend in Scopes

We need to finish wrapping all 3 chunks of the backend in scopes and have basic error handling.

Implement Event Queue

The event queue data structure underlies all of feather processing - an initial implementation in scopes must be completed for us to do input processing in a sane way.