Project Roadmap

[nicholatian]

Using our revolutionary new talk issue label as a sentinel for discussion threads, this one will serve as a rendezvous for all of the high-level planning for Carta.

To my knowledge, no other GUI toolkit in the wild is data-oriented; object-oriented APIs predominate heavily. This break in trend is in the interest of user empowerment and the core mission of Carta: Provide a user interface tool kit driven by productivity.

So far, we have found four tenets of the project’s nature in development:

1. code is totally ANSI C†
2. graphics are constructed with scalable vectors
3. the API is data-oriented
4. software rendering should be feasible, at minimum as a fallback

Moving on into the meat of Carta, we have, as an alternative conceptual base to Object, the ‘item’, which is simply any given thing that appears on the screen. Carta provides five fundamental items with which a powerful GUI can be created:

1. Text – An abstract term for high-density information intended for humans. Usually is composed of literal text, but it is not limited to that
2. Plaster – The unit of visual foundation applied onto an interface. Comprised of colour, gradients, and simple patterns constructable with math
3. Overlay – Modifies the view with the purpose of controlling focus. Like Plaster, but with filters and adjustments instead of colours and gradients
4. Picture – A canvas of pixels providing the finest granularity of image control. Useful for the centrepieces of many applications, including image editors, code editors, and so on
5. Reflection – Takes an input from a source (such as a screen partition or external video source) and displays it. A good visual example is a video editing software showing a miniature of the camera view

There is a sixth kind of construct in Carta, but I have separated it from the list as it is more meta than literal. It is the Partition, and it provides the delineation left by our departure from object oriented programming and its easy provisioning of boundaries with its veneer of class hierarchies. Partitions demarcate a portion of the viewport, in units of the nominal resolution, and this demarcation can be referenced when compiling the state of the UI for rendering.

These systems are designed to be fundamentally excellent for UIs of power, and this is proven with Carta’s signature functionality: zooming. The power of Carta in space is detailed above, and zooming is its power in time. An intelligent zoom in a program is nothing more than an increase in the amount of information to view. This maintains the amount of information on the screen at any given time to be relatively constant, while allowing potentially infinite amounts of information to be processed easily by human beings. What you see is what you get, brought up to speed for the information age.

---

† “ANSI C” colloquially refers to the 1989 standardisation of the C programming language by the ANSI committee X3J11.

[nicholatian]

Carta addresses several different scopes in its programming. These are, in order from least to most abstract:

1. Driving the display of graphics
2. Modeling the UI fundamentals (described above)
3. Modeling the UI event loop
4. Creating a default toolkit with a prescribed look-and-feel
5. Proving Carta’s capabilities with a demo program

Driving the display of graphics

Nothing more than software-backed rendering is needed, although hardware accelerated rendering is always a plus. SDL2 can be dropped in to achieve this.

Modeling the UI fundamentals

These are many a struct body, along with functions for their initialisation and finalisation. This includes outlining the Partition struct. With the display driver in place, a basic system for nominal screen resolution can be fashioned.

Modeling the UI event loop

These can piggyback off of SDL2’s event loop, using a synchronised event system to pass a function pointer to call, along with a monad contextualising it.

Creating a default toolkit with a prescribed look-and-feel

This includes all of the things people typically call “UI widgets”. Instead of providing a collection of objects as originally modeled by Microsoft for their Windows UI, item visuals can be constructed as arrays of more generic structures, atomising not only their interactive properties but also their very composition.

Proving Carta’s capabilities with a demo program

This may ultimately happen outside the repository, but nonetheless it should serve a very convincing proof of concept for what makes Carta so powerful and unique. This is the final step of Carta’s development before @aquefir moves on to creating products with it.

[nicholatian]

UIs in Carta can be understood as exhaustive maps of information. This information is navigated solely by zooming.

Zooming: a seventh fundamental

Given a viewport, one can select some or all of the screen (by Partition) and invoke a zoom event. This will either be to zoom in or to zoom out. Zoom events cause more than just a redraw of the framebuffer; they imply the reconstruction of the visible layout of the UI in much the same way. Carta’s public API provides hooks for applications to react to these events.

Modeling the viewport

For Carta, pixels are no object, but screens themselves are quite static. Carta treats its canvas as nothing more than a static framebuffer, given a fixed aspect ratio and abstract but constant dimensions. While many consumer electronics promote a wide variety of screen sizes and aspect ratios, this is because consumer UI models, like Material Design, mould themselves onto anything and everything like putty. Carta is a UI framework of power, and application designers must know the screen size, orientation, and aspect ratio that they are targeting. However, they need not know them to an exact precision; the number of pixels can be arbitrary as Carta is vectorised, and aspect ratio can be visually fudged when it differs only slightly. For application developers, the screen size they must know is in a sense of retina, nothing more or less.