@jamesnvc if you had such bindings availables would you have used it for your own ECS framework ?
The idea when creating the bindings was really to keep a 1 to 1 mapping with sdl api.
The only differences are:
SDL handles are put in interdependent blobs, so it is memory safe and garbage collection safe.
SDL flags are translated to user readable atoms.
everything is type checked through library(error) with must_be, even blobs and flags.
@jan would you consider the inclusions of such bindings into swi-prolog itself ? one major advantage would be that user could experiment writing gui applications in prolog without having to install a c/c++ compiler.
The bindings are currently really bare-bone and ideally, we would also have bindings to cairo and pango to be able to draw more complex forms and write text.
Very nice! To be honest, I might still have stuck with my approach for my ECS framework, as my SDL bindings are a bit “higher-level”, or at least more specific to my use-cases. e.g. my wrapper around SDL_PollEvent converts the enum value into an atom and builds out a list-of-pairs structure for the other data.
Plus, it was an opportunity for me to learn SDL and CMake
I’ve been trying out SDL_ttf; simple enough, fits in well with the rest of SDL.
My first intuition says not as a separate framework. As said, I would be interested as an add-on to xpce. That keeps all GUI tasks in one coherent framework and deals only once with the dependencies and binding problems. The main challenge is probably that xpce is designed using an event driven call-back model. That is quite common in GUIs, but probably not how we want to deal with a gaming module that uses “Prolog style coding”. That might be fairly easy to fix by associating a Prolog thread to a game window and feed the SDL events into a message queue. That allows read-style as well as mapping to a lazy list.
To be clear, I am not advocating upstreaming some gui framework like my experimental qml like thing.
Just the 1 to 1 bindings of SDL, Cairo and Pango so that people can use it like if they used SDL, Cairo or Pango directly but in Prolog.
I know that immediate mode gui like imgui uses a fairly low level api from SDL that just renders vertices. so the gui framework job is to serialize all drawing into these low level vertices and then just dump these to SDL.
Maybe a similar things could be done inside xpce ?
the hard part is how to do this rendering gpu native, as doing it with cairo is fairly slow and probably not adapted for highly dynamic content like games.
It makes handling state as a (backtrackable) Prolog term hard. We also have that issue for example in Pengines/SWISH. To maintain state we use a thread that keeps the state and communicate with that. That idea can probably be used here as well.
It is not entirely clear whether one should keep state in a Prolog term or as dynamic predicates though. The database might look less Prolog like, but makes it fast and natural to express statements about the world. Backtracking on a Prolog terms is nice for planning and revert partial compound modifications. Some of this can be done using transaction/2. Using the dynamic database also allows for concurrent exploration. David Warren’s work on representing dynamic data as a Prolog term could be interesting as well. For short, there are a lot of things to think about and probably not a single answer
