Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Fejix

Fejix is a cross-platform system abstraction layer for GUI. This library is intended to be used as a base for GUI frameworks, game engines, emulators, and other kinds of tools that draw their UI themselves, i.e. not using a native system framework.

Why

Imagine that you want to create a new GUI framework. This is actually a pretty reasonable desire: no single GUI framework can fit all programming paradigms, design languages, application needs, or simply developer moods.

To create a GUI framework you need:

  1. A runtime: a program entrypoint, an event loop, app lifecycle handling, timers, time measurement utilities, logging, standard library utilites, multithreading, multiprocessing, background threads, etc.

    Fejix does not have any of that on purpose: being your own runtime.

  2. A system abstraction: managing windows, window menus, status icons, notifications, input, clipboard, initializing OpenGL/Vulkan, etc.

    This is what Fejix does.

  3. A renderer: actually drawing something with OpenGL/Vulkan/etc.

    Fejix does not do this at all. Draw everything on your own.

  4. UI logic: widgets, layout, and everything that forms the final API of the GUI framework.

    This is the most interesting and the most important part.

This library was inspired by winit and SDL, but deliberately omits rendering and runtime stuff — you have the freedom to choose all that.

Features

This project is in its earliest stage of development.

The most intereseting thing to see here is this emoji: 🌸

  • No dependencies (other than system packages)
  • Simple object-oriented-ish C API that is easy to write bindings for

Planned advanced features:

  • unreplaceable system GUI primitives like window menus or status icons
  • System compositor integration (offloading window composition to the server)
  • Display management (support for multiple displays, e.g. external dislpays on iPhone or choosing a specific display under Linux Framebuffer)

Tradeoffs:

  • The (customizable) allocator must abort the program on out-of-memory, simply because the library is too complex to handle OOMs everywhere
  • Nearly all Fejix functions must be called from the main thread. This is because the underlying system APIs are just single-threaded. UIKit does not allow multi-threading. Windows API poses weird limitations to creating windows in multiple threads. It's a mess!

About

Cross-platform system abstraction layer for GUI (windows, input, etc.)

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages