axelson

axelson

Scenic Core Team

Okay, posting this day’s talk by @boydm:

ElixirConf 2017 - Elixir Native UI - Boyd Multerer

I will be showing and discussing an Elixir-Native UI package that only depends on OpenGL (through glut). No browser, no wxWidgets, just Erlang, Elixir and OpenGL… Intended for embedded applications, but with possibilities for use beyond.

The framework supports multiple scenes, animations, input, forms, fonts, and more. I’m trying to optimize it for small package size, as few dependencies as possible, and nice co-existence in an embedded application.

This is a work in progress, but is pretty far along. Hope to release a beta in the next few months. Think of it as an opportunity to both preview a large project and give feedback before the first release.

All talks thread:

Showing Posts 1 to 10

axelson

axelson OP

Scenic Core Team

I want to say that I really enjoyed this talk. And I am very excited to be able to play with code. I would love to build something on top of a framework like this. It looks like really nice work and I’m impressed by many of the small touches that are already included (such as the live per-frame performance breakdown and well-done translations). This makes me much more excited about Nerves as well!

Now I just need to patiently wait for the code to be released :slight_smile:

Also it looks like I wasn’t the only one that enjoyed it:

https://twitter.com/chris_mccord/status/908183839209648134

aseigo

aseigo

I think this is really nice for very small systems, but anything near the size of a RPi .. I’m unconvinced.

Building a UI toolkit that works well is really, really hard. The old “last 10% takes 90% of the effort” adage is 10x worse for UI frameworks. The last 1% takes 50% of the time IME. I would much, much rather see good integration with an existing and mature technology like QtQuick. It is declarative, provides all sorts of absolutely wonderful features and flexibility, including the ability to inline OpenGL shaders etc. And it works a dream on small-ish devices that can run a moderately modern OS like Linux, including RPi grade hardware.

Sequential programming of UIs is, outside of special cases like low-level game development, done imho. It is not realistic for the average human developer to produce UIs that fit modern expectations with a sequential API. The need to manage interactions between components, animations, data, etc. is just tool complex. When the more-or-less-static UI paradigm of WIMP started to die, that was really the end of sequential UI programming. For that reason, having a declarative UI system, as seen in QtQuick, is currently the best route.

(Prior to my current focus back on distributed systems, I spent ~15 years doing UI/UX R&D at medium and large companies .. the above is borne of that experience :slight_smile:

kokolegorille

kokolegorille

@aseigo You are famous in the Linux world for being one of the lead promotor of KDE :slight_smile:

Eiji

Eiji

It’s really interesting. Anyone know if they will support percentage values? I would like to work with auto-fit elements. They will probably not allow for editing title bar. I would like to have a ready solution like tabs in Vivaldi browser, but by default I would like to have system colors/icons in it (also in vertical mode). Maybe someone will create a library for it - if so I will be a first developer that will try it. :smiley:

JEG2

JEG2

Author of Designing Elixir Systems with OTP

This is one of the cooler talks I have watched so far.

I think everyone that complains about Elixir not being good for high performance work needs to watch this talk. It shows how you handle such needs masterfully. Heck it’s even using a Port currently, so it’s not yet as efficient as it could be.

I am super excited to play with this code!

aseigo

aseigo

OpenGL (and similar APIs such as Vulcan) are so magical because they reach rather deep down into the hardware that is made for this specific use case making whatever you are driving it with a side-thought in terms of performance. I’ve used tools which live-compiled OpenGL embedded in / driven by Javascript (way before WebGL was a thing :), and I can only imagine how insane having Elixir’s hot code reload instead will be.

I think there is a huge potential here as well for applications where computation is spread out among many machines, or distributed applications like we’re already seeing people do with Nerves with multiple small devices working together with Elixir’s clustering, which end up rendering to one or more(!) nodes in the same cluster that have OpenGL capable hardware attached.

I do think that with the right API to drive such a thing, hardware accelerated graphics driven by clustered Elixir could be a game changer in many areas ..

aseigo

aseigo

It at least allowed me to learn a few things about this problem area :slight_smile: After more than a dozen years working on KDE/Qt as a core developer, I learned a lot about how painful some approaches are. I really do think Elixir would take off in a whole new way if it were possible to build beautiful native UIs with it, so I’m hopeful this all turns out well.

When I watched this video I thought, “Boy, this looks a lot like what an openGL game dev would make …” (both because it looks quite well done, lots of little details in there that are not at all easy, and because of the general approach), and when I looked up the person who gave the talk I was pleasantly surprised .. :slight_smile:

(Were I less busy with other things at the moment, marrying QtQuick and Elixir would be the sort of project that I would find quite interesting to hack on; some people have started on such things, so I hold out hope ..)

jackalcooper

jackalcooper

Awesome talk but no code available for now?

mbenatti

mbenatti

He say… not ready for public yet…(some work to do)

kylethebaker

kylethebaker

I’m in the same boat as everyone else, really excited to play around with this. Tracking the UI events using processes looks cool, it looks like api for this piece is modeled after genservers which makes it feel familiar. It seems like all of the tools would be a place to build a “retained mode” style ui library using this as the backbone, where you could have predefined ui elements and positioning.

I don’t know much about OpenGL, I’m curious how this compares to wxWidgets and the wx/gl erlang libraries. I know that wx has a lot of predefined ui stuff, but I think you are able to create more ‘freeform’ things with it as well. The api here certainly looks a lot nicer and more elixiry. The notes mention that he’s using glut, which I guess is another OpenGL toolkit. Does he say in the talk if that binding happens using ports?

He does a nice overview of the API here, hopefully we’ll be able to check out the internals soon enough.

The Colors.Style code he showed looked like a good case for compile time code generation, rather than manually creating a function for each of the css spec named colors. I whipped something together using colors directly from the spec, though I kind of like the configuration-esque aesthetic of his. I just copy-pasted directly from the page and did some minor search-replaces to make it easier to parse.

defmodule CssColors do

  # Colors definitions taken from csswg Extended Color / SVG spec
  #
  # https://www.w3.org/TR/SVG/types.html#ColorKeywords
  # ...
  # antiquewhite 250,235,215
  # aqua 0,255,255
  # aquamarine 127,255,212
  # ...
  @colors "priv/colors-spec" |> File.read!

  def to_rgba({r, g, b, a}),
    do: {r, g, b, a}

  def to_rgba({r, g, b}),
    do: {r, g, b, 0xFF}

  def to_rgba(<<r::size(8), g::size(8), b::size(8), a::size(8)>>),
    do: {r, g, b, a}

  def to_rgba(named) when is_atom(named),
    do: to_rgba(named, 0xFF)

  def to_rgba({named, alpha}) when is_atom(named),
    do: to_rgba(named, alpha)

  for line <- String.split(@colors, "\n", trim: true) do
    [name_str, rgb_str] = String.split(line)
    name = String.to_atom(name_str)
    [r, g, b] = String.split(rgb_str, ",") |> Enum.map(&String.to_integer/1)
    def to_rgba(unquote(name), a), do: {unquote(r), unquote(g), unquote(b), a}
  end
end

Where Next? Top

Trending in Talks Top

alexslade
This is a thread to organise resources while we wait for official posting of videos. I’ve committed to keeping this post updated, please ...
New
CodeSync
LT: Skode: an ASCII shorthand for audio experimentation - Joseph Stewart | ElixirConf EU 2026 Comments welcome! View the ...
New
bartblast
This is the follow-up to my ElixirConf EU talk in Malaga, which was mostly about the local-first problem and where sync engines stand on ...
New
ElixirConf
Failing to Introduce Elixir - John Darrington https://www.youtube.com/watch?v=KjAH68yVnh8 Comments welcome! View the <span class="hasht...
New
CodeSync
Rebuilding Workflow Orchestration in Elixir: The Story of Gust - Marcio Klepacz | ElixirConf EU 2026 Comments welcome! Vi...
New
CodeSync
What if you could build production-ready RAG entirely in Elixir? George Guimarães, ElixirConfEU 2026 https://www.youtube.com/watch?v=tNB...
New
ElixirConf
Lightning Talk: Ivy Markwell - Data migrations with Monarch | ElixirConf US 2025 https://www.youtube.com/watch?v=AF1z6Z3bJKY Comments ...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews