alloy/TODO.mess at master · Shirakumo/alloy · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
# Alloy Todo
It is highly recommended to use a tool like the ''magit-todos''(https://github.com/alphapapa/magit-todos) package to track comments in the code base that mark problems in the implementation. These are typically comments starting with ``KLUDGE``, ``TODO``, or ``FIXME``.

Bigger tasks that do not fit onto a specific location in the code are described in individual sections here. The tasks are roughly divided up according to estimated amount of effort/time investment required.

**If you begin working on one of these tasks, please do so on a separate branch named after the task, create a dummy commit, and //open a PR immediately// to track progress and allow discussion of the issue.** You should do this even if you are not yet entirely clear on how to tackle the task. The PR can be used to get help and discuss potential forms of attack. Once you fully resolve one of these tasks, please remove it from this document. If you partially resolve or otherwise affect a task, similarly please update its status here.

## Low Effort Tasks
### UBOs for the OpenGL Backend
Using Uniform Buffer Objects would allow us to avoid having to re-set common uniform parameters for every draw call, increasing performance.

### Additional Component Types
The following component types would be very nice to offer as well:

- ``range``
  Allow selecting a range on a slider
- ``date``, ``time``, ``datetime``
  Allow selecting date-like things, with a convenient way to enter that information
- ``color``
  Present a color picker popup with an HSV arrangement
- ``file``
  Opens the file dialog. This either requires the ''file-select''(https://shinmera.com/docs/file-select) library which introduces a CFFI dependency, or implementing our own dialog. The former is problematic due to dependency chains, so should be an optional system, and the latter is a lot of effort to implement.
- ``password``
  A simple variation on the standard ``input-line`` that optionally hides the input with a toggle-button to show it.

## Medium Effort Tasks
### Gradients in the OpenGL Backend
Currently gradients only exist as a protocol, but are not actually implemented. A gradient should create a vertex buffer with the correct geometry (2D verts + colors). This geometry only needs to be created once per gradient, and can then be scaled and transformed to fit sizes.

### Using Cluffer for Text Buffers
The ''Cluffer''(https://github.com/robert-strandh/Cluffer) library implements a protocol suited for text editor buffers. We should make use of it to implement our text editor components instead of rolling our own ad-hoc buffer system.

### Query System DPI Information
Currently we rely on the user to supply actual DPI information about the real system we are running on. It would be great if there was an Alloy extension that allowed querying the DPI information from the system. Several challenges exist here:

- The DPI information is highly display system specific, meaning we would need implementations for Win32, Cocoa, X11, and Wayland in the least.
- The DPI information can change depending on where the window is on screen. To make this independent of the backend used, the DPI query protocol should allow passing an ``extent`` in screen coordinates for which the DPI is returned. If no such extent is passed, the DPI of the primary monitor should be returned.
- A window may potentially exist on two separate monitors with different DPI values at once. In this case the system should offer some kind of conflict resolution.
- Ideally this would be integrated into the alloy-windowing protocol to automatically track and update the DPI of a window.

### Software Rasteriser for the Simple Protocol
An implementation of the Simple shape drawing protocol using a native Lisp software rasteriser (outputting to an UB8 packed array) would be great as a step-in for direct rendering interfaces. Libraries like Vecto and cl-vectors should aid in this. One concern is the ultimate rendering performance since Alloy's partial redrawing protocol is underbaked atm.

### Framebuffer Backend
With the new ''Framebuffers''(https://shirakumo.org/docs/framebuffers) library and the above software rasteriser we should have the path cleared for a fully lisp-native backend. This extension would implement the windowing protocol similar to alloy-glfw and tie it into the software rasteriser backend.

## High Effort Tasks
### Cocoa Backend
This would be done in two steps:

1. Implement a backend similar to the opengl backend that implements the drawing primitives of the Simple protocol and the input primitives of base Alloy. This would allow rendering to and interacting with Alloy UI from a native Cocoa window.
2. Implement a backend that translates standard components to Cocoa native components instead. Whether doing such a translation is feasible is currently unexplored.

### GTK Backend
This would be done in two steps:

1. Implement a backend similar to the opengl backend that implements the drawing primitives of the Simple protocol and the input primitives of base Alloy. This would allow rendering to and interacting with Alloy UI from a native GTK window.
2. Implement a backend that translates standard components to GTK native components instead. Whether doing such a translation is feasible is currently unexplored.

### Qt Backend
This would be done in two steps:

1. Implement a backend similar to the opengl backend that implements the drawing primitives of the Simple protocol and the input primitives of base Alloy. This would allow rendering to and interacting with Alloy UI from a native Qt window.
2. Implement a backend that translates standard components to Qt native components instead. Whether doing such a translation is feasible is currently unexplored.

### Wayland Backend
Implement a backend similar to the opengl backend that implements the drawing primitives of the Simple protocol and the input primitives of base Alloy. This would allow rendering to and interacting with Alloy UI from a native Wayland window.

### Win32 Backend
This would be done in two steps:

1. Implement a backend similar to the opengl backend that implements the drawing primitives of the Simple protocol and the input primitives of base Alloy. This would allow rendering to and interacting with Alloy UI from a native Win32 window.
2. Implement a backend that translates standard components to Win32/WPF native components instead. Whether doing such a translation is feasible is currently unexplored.

### X11 Backend
Implement a backend similar to the opengl backend that implements the drawing primitives of the Simple protocol and the input primitives of base Alloy. This would allow rendering to and interacting with Alloy UI from a native X11 window.

### Code Editor
A fully-fledged code editor component based on the input-box with support for syntax highlighting and all that stuff. I'm sure you can come up with a whole pile of features this should have yourself. Should probably also be an optional system like alloy-editor.

### New Text Layouter
This should probably be an independent library that implements a general text layouting algorithm while letting the user hook in to provide font information like glyph sizing, advancement, spacing, fallback chains, etc, and then based on a portable styling protocol, invoke a function with the necessary glyph information to "emit" a fully layouted glyph.

So given a box to fit the text in and a string, the layouter should take care of:

- Line breaking (See 'UAX-14''(https://shinmera.com/docs/uax-14))
- LtR, RtL, TtB, BtT orientations
- Start/End/Middle alignment in both directions
- BiDi text flipping (See ''UAX-9''(https://shinmera.com/docs/uax-9))
- Combining diacritics
- Switching and combining of text styling (bold, italic, supertext, subtext, strike, underline, monospace, outline, etc)
- Selecting the correct font for any particular glyph based on a fallback chain
- Offering a callback to provide information about a particular font:
  - line-height
  - space-size
  - base-scale
- During layouting, invoking a user function for each glyph to get its characteristics under a particular font:
  - x/y-offset
  - w/h
  - xadvance
  - kerning between two glyphs
- Once layouted, invoking a user function with all necessary information to emit the glyph:
  - glyph X-/Y-/X+/Y+
  - anxilliary information the user requires like:
    - U-/V-/U+/V+
  - properties derived from the styling like:
    - color
    - outline
    - ...