How about crowdfunding for scenic-based libraries/projects?

[Eiji]

Hey, as you probably saw I have created this topic:

Scenic with optimus, system notifications and tray icon

Hey, I would like to compile scenic-based project into single executable native file. At start it should be tray icon which optionally runs scenic window (for example for first run window or settings window) and it should run some job in background while notifying end-user about results (if any). Optimus For now I’m using optimus library for parsing cli options. The problem is that I can’t get it to work with scenic. I have tried to setup it with escript, but scenic is using its glfw driver exe…

As I had wrote there I have made some research and did not found anything helpful. Therefore I was almost sure that there is no satisfying answer for it and posted such question to be sure. The problem is that linked question covers only few really basic things for specific use case of native desktop app.

I have just took a look at my browser (Vivaldi) settings window which is fully themed, have great i18n support and it’s just huge (16 categories). Writing it in scenic would take way too much time especially if we want to write proper dynamic search code and 1:1 theme support. Look that’s just settings window of first app which I had in mind.

Some time ago I was looking on scenic from documentation side and on source code examples. While code is awesome keeping in mind that everything is rendered using OpenGL it’s still not enough for comfortable developing lots of really simple apps.

I have few ideas for scenic-based libraries which would be extremely usable for typical native apps (something more than calculator). I wanted anyway to release such libraries as open source projects available on GitLab. Unfortunately I’m too bused now to fully focus on open source work without any founds and what I’m doing for community last time is mostly limited to only replying on some questions on this forum.

Here goes my idea: crowdfunding. At start I can give ~130 USD - maybe more if it would become more popular. I know that’s not a lot, but hope other people would also help. All collected money would go in one of 2 ways:

1. All / most for me if there would be really big amount of money. In such case I would finish all current works and I will fully focus on open source work since I would not need to worry about anything other.
   
   In this scenario I would describe every idea in #your-libraries-projects:libraries category and I will notify about progress in specified period of time (let’s say 2-4 weeks). The only job offers which I expect are researching and writing NIFs.
   

2. Most / all for Elixir job offers which would be available in one of those 2 forms:
   a) pay for research
   b) pay for 1.0.0 release
   
   In this scenario I would describe details about public API, requirements, (at least part of) dependencies etc. in #community:elixir-jobs.

Here is a sneak peek:

0. Changes to scenic and its drivers like scenic_driver_glfw medium and high

1. Advanced themes medium and high
   Well … Just take a look at KDE/Plasma and see how much we can improve.
   I expect 3 job offers here:

   • 1 research
   • 2 libraries (split like ecto + ecto_sql)

2. Frame-less app medium
   Partially related to 1st point. Custom advanced titlebar.
   I expect 3 job offers here:

   • 1 research
   • 2 libraries (again split like ecto + ecto_sql)

3. Advanced TabBar medium
   Customizable like old Firefox - definitely something more than component with few predefined buttons …
   Single job offer.

4. Advanced form and its components easy
   Something like advanced version of HTML forms, but without CSS3 mess)
   Also single job offer.

5. Advanced settings easy
   Categories, groups and layouts related …
   Again single job offer.

6. OS integration high
   This would be split in the number of important OS features. For now I see 4 jobs offers:

   • MIME types and default applications
   • System notifications
   • TaskBar advanced support
   • Tray icon (simple and advanced version)

7. Diagrams, Graphs and related medium
   Maybe few small jobs (like each diagram type) or maybe one bigger.

and even more …

I have in mind bigger projects like scenic-based version manager, ecto designer, M.U.G.E.N. - like advanced 2D fight game engine, card game engine, but those are less important. Of course ecto designer would be really powerful and important, but not for typical OS-like app.

It’s all I have right now. Of course I can share full details at any time, but not sure if it’s even worth to write it without know your opinions. What do you think about it? Would you like to see detailed project information? Which crowdfunding service is good in your opinion?

[stefanchrobot]

If I understand correctly, you want to build desktop apps, right? That’s what I’m getting from showing a tray icon, etc.

If that’s the case, I think Scenic is not the right tool for that - I’d suggest going with platform specific components/widgets. I know that cross-platform UIs sound very nice, but in reality native widgets come on top when you really want platform-like feel (same story as on mobile). While wxErlang might be useful in some cases, you’ll hit a wall the second you’ll try to play a sound.

I’m working on an Elixir library for building component-based desktop apps, but that’s still in the making and not a priority till at least March.

[Eiji]

@stefanchrobot

If I understand correctly, you want to build desktop apps, right? That’s what I’m getting from showing a tray icon, etc.

exactly

@stefanchrobot

If that’s the case, I think Scenic is not the right tool for that.

Honestly OpenGL on which scenic (to be more precise scenic_driver_glfw) is based is enough. Look that awesome KDE/Plasma compositor is also written allows to use OpenGL engine in versions 2.0 and 3.1. The biggest problem is that I don’t have enough experience in OpenGL programming.

@stefanchrobot

I’d suggest going with platform specific components/widgets.

Nope, I have a much different plan (more would be available in details).

@stefanchrobot

I know that cross-platform UIs sound very nice, but in reality native widgets come on top when you really want platform-like feel (same story as on mobile)

Look every OS/distribution/desktop environment have its own theme files. There is only a matter of proper research, builds structs based on it and finally write a code that handles them.

@stefanchrobot

While wxErlang might be useful in some cases, you’ll hit a wall the second you’ll try to play a sound.

While sounds are interesting for native apps I don’t see them around scenic topic. It’s mostly about drawing components with their themes properly.

@stefanchrobot

I’m working on an Elixir library for building component-based desktop apps, but that’s still in the making and not a priority till at least March.

I would suggest to hold on in case people would find my idea interesting. As you can see job offers have their own level, so I would have some work as well for newbie as well for more experienced developers which are familiar with NIFs. I have a plan to support all OS/distribution/desktop environment themes, so components could look like native.

[stefanchrobot]

@Eiji

I have a plan to support all OS/distribution/desktop environment themes, so components could look like native.

There’s a huge difference between looking native and actually being native. There was a great blog post that described a lot of features that you get for free just by using native components on Mac (sorry, I can’t seem to find it…). Same story applies to Windows. If you don’t go with native components, you end up with some users thinking “I should be able to select this text” or “I should be able to right-click here”. For most cases you probably don’t care, but you need to at least understand the limitations of going cross-platform vs native.

[OvermindDL1]

@stefanchrobot

If you don’t go with native components, you end up with some users thinking “I should be able to select this text” or “I should be able to right-click here”. For most cases you probably don’t care, but you need to at least understand the limitations of going cross-platform vs native.

Ugh, the number of times at home I alt+click on a window splitter or something and can’t drag the window around drives my bonkers at times… >.>

/me points to Discord most recently…

[Eiji]

@stefanchrobot

There’s a huge difference between looking native and actually being native. There was a great blog post that described a lot of features that you get for free just by using native components on Mac (sorry, I can’t seem to find it…). Same story applies to Windows. If you don’t go with native components, you end up with some users thinking “I should be able to select this text” or “I should be able to right-click here”. For most cases you probably don’t care, but you need to at least understand the limitations of going cross-platform vs native.

Yeah, I’m definitely to cross-platform and look like native. The good point of that is that we can style app to look like on different OS/distribution/desktop environment - especially if we are talking about so poorly configurable Windows. I always want to see Oxygen themes used easily there.

@OvermindDL1

Ugh, the number of times at home I alt+click on a window splitter or something and can’t drag the window around drives my bonkers at times… >.>

Exactly! Now think that any app can simulate any theme and window manager behaviour! Of course handling such cases is also expected in my plans.

[ConnorRigby]

Unfortunately creating a static binary from an Erlang project is pretty tough/not possible as far as i know. Even if you could do that, recreating the platform independent ui elements would be really tedious and not worth it in my opinion. I don’t think scenic or Elixir would be the right tool for this job

[Eiji]

@ConnorRigby

Unfortunately creating a static binary from an Erlang project is pretty tough/not possible as far as i know.

Maybe I’m wrong, but escript and distillery releases are already doing that. The only problem with distillery releases is that instead of your input arguments you have distillery arguments which are good at dev and nerves sides.

If I remember correctly nerves releases already does not requires installation of any Erlang and Elixir on target devices.

@ConnorRigby

Even if you could do that, recreating the platform independent ui elements would be really tedious and not worth it in my opinion.

For sure, I don’t want to create few different GUI apps for just one API interface. It would be doable, but really limited. Instead of that I want to fetch as much information from system as possible and use them in OpenGL as same as scenic_driver_glfw does it already. The only difference here is that scenic have less components and it has it’s own predefined styles. I just want to add more components and better theme engine.

@ConnorRigby

I don’t think scenic or Elixir would be the right tool for this job

I saw some small games written in Elixir already. The only problem is that they were launched from iex session. It’s just a matter of making it work with escript or do it in similar way.

[ConnorRigby]

I think escript can have issues in practice, but may be a solution.

@Eiji

If I remember correctly nerves releases already does not requires installation of any Erlang and Elixir on target devices.

In Nerves we still install Erlang. There are issues when cross compiling and bundling ERTS, which will become a problem if you want to distribute binaries for other platforms. So if you have say a CI/CD instance that builds binaries for distribution (most/all native applications do this), you wouldn’t be able do it all in one machine

@Eiji

Instead of that I want to fetch as much information from system as possible and use them in OpenGL as same as scenic_driver_glfw does it already

OpenGL has no idea what a system is. OpenGL is a rendering engine. You may be confusing glfw. glfw has native support for Windows, macOS and many Unix-like systems using the X Window System, such as Linux and FreeBSD.

The only difference here is that scenic have less components and it has it’s own predefined styles. I just want to add more components and better theme engine.

This is a huge difference. Scenic is not using any native operating system features directly. it relies on glfw to do all the work behind the scenes. This means that there is no access to native operating system ui components. The only thing scenic_driver_glfw is concerned with is creating a “window” to draw pixels too. There isn’t any shapes, text, anything. The only thing glfw does is give you a raw surface to output pixels too. there would need to be some sort of abstraction to generic OS ui components. Every component would need to map to other components. Some components just don’t map over in different UI environments. Examples:

• my window manager does not use a Cross in the corner to indicate closing a window
• not all window managers put components in the same place, IE Ubuntu has the cross in the left corner of a window

Furthermore systems like X11 don’t even have the concept of many components in say the Windows UI. There’s no button for example.

Dynamically loading the same code, but displaying native components would be pretty much impossible. (okay not impossible, nothings impossible, but you get the point). This is why this doesn’t exist yet and anything wanting code uniformity is a framework that implements its own components. So Scenic, GTK, QT, .NET etc.

[Eiji]

@ConnorRigby

OpenGL has no idea what a system is. OpenGL is a rendering engine. You may be confusing glfw . glfw has native support for Windows, macOS and many Unix-like systems using the X Window System, such as Linux and FreeBSD.

Yes, 100% correct - I know this.

Look that you can fetch information about current and available themes without OpenGL. Sometimes you would need to read standard Linux configuration files … some things you would need to fetch from dll files in Windows … sometimes … The idea is to write code which would parse such files (or use NIFs if it’s too much work) and save them into Elixir structs. Based on such data we can create GUI scenic-like API in order to draw same component types on dynamically fetched theme information. In short I would like to draw any OS/distribution/desktop environment components in OpenGL on all supported platforms i.e. XP - like button and MacOS-like progress bar in window with Oxygen theme even if just for fun.

@ConnorRigby

This is a huge difference. Scenic is not using any native operating system features directly. it relies on glfw to do all the work behind the scenes. This means that there is no access to native operating system ui components.

Again 100% correct - I just need access to some configuration files - not API for drawing OS components.

@ConnorRigby

The only thing scenic_driver_glfw is concerned with is creating a “window” to draw pixels too. There isn’t any shapes, text, anything. The only thing glfw does is give you a raw surface to output pixels too. there would need to be some sort of abstraction to generic OS ui components.

Which now is done by scenic. In same way scenic is drawing in OpenGL button I want to have “advanced” button i.e. just more them options.

@ConnorRigby

Every component would need to map to other components. Some components just don’t map over in different UI environments.

I believe that most common components are themed pretty well. Of course there could be WinAPI component which is not available in GTK+ or Qt - in such cases I would simply return: {:error, :not_supported} and force developer to choose different theme or component or even draw it’s own component based on specified theme colors.

@ConnorRigby

• my window manager does not use a Cross in the corner to indicate closing a window

I’m curious if it’s possible to draw transparent window which could simulate different window manager behaviours.

@ConnorRigby

• not all window managers put components in the same place, IE Ubuntu has the cross in the left corner of a window

It’s also saved in theme files. I don’t know exactly where, but I’m sure that’s possible to fetch such information.

@ConnorRigby

Furthermore systems like X11 don’t even have the concept of many components in say the Windows UI. There’s no button for example.

I’m not talking about native X11, window managers etc. I’m talking about:

1. Themes for window managers (for styling custom titlebar)
2. Themes for GTK+, Qt, WinAPI (XP, Vista, 7, etc.)
3. Icons for 2nd point themes

@ConnorRigby

Dynamically loading the same code, but displaying native components would be pretty much impossible.

Again, it’s not a matter about using native components - it’s a matter to fetch information about them and draw them on our own in OpenGL.

@ConnorRigby

This is why this doesn’t exist yet and anything wanting code uniformity is a framework that implements its own components.

Yup, it’s own components - just rules (colors and other styles) instead of predefined (dark vs light theme) would be fetched from existing themes.

[ConnorRigby]

@Eiji

Again 100% correct - I just need access to some configuration files - not API for drawing OS components.

These “configuration files” you are looking for don’t exist like you think they do. OS specific UI data isn’t stored in a config file. Its baked into the OS, and requires integration via C/C++ bindings usually.

@Eiji

Which now is done by scenic . In same way scenic is drawing in OpenGL button I want to have “advanced” button i.e. just more them options.

This is what Scenic calls primitives. More can be added relatively easily to the Scenic source, but not externally via another lib.

@Eiji

I’m curious if it’s possible to draw transparent window which could simulate different window manager behaviours.

again possible does not mean reasonable. This is why projects like GTK, WX, QT etc exist. You get the same behaviour on every platform, but not using native components.

@Eiji

It’s also saved in theme files. I don’t know exactly where, but I’m sure that’s possible to fetch such information.

There is no such thing as “theme files” like you are describing. You must build an application that uses the native components as they were designed. IE red-cross-right-corner.png isn’t a thing that can just be looked up somewhere. You need to be in the framework it was designed in.

[Eiji]

@ConnorRigby

These “configuration files” you are looking for don’t exist like you think they do. OS specific UI data isn’t stored in a config file. Its baked into the OS, and requires integration via C/C++ bindings usually.

Are you 100% sure? Of course there are lots of ways to save information about themes. I’m almost sure that without C/C++/C# or similar you will not be able to extract icons from *.dll files, but it’s not like that all things are written in *.so or binary files …

Take a look at this fragment:

[Colors:Button]
BackgroundAlternate=77,77,77
BackgroundNormal=49,54,59
DecorationFocus=61,174,233
DecorationHover=61,174,233
ForegroundActive=61,174,233
ForegroundInactive=189,195,199
ForegroundLink=41,128,185
ForegroundNegative=218,68,83
ForegroundNeutral=246,116,0
ForegroundNormal=239,240,241
ForegroundPositive=39,174,96
ForegroundVisited=127,140,141

I found it in: ~/.kde4/share/apps/color-schemes/Breeze\ Dark.colors. Also in KDE/Plasma and GTK+ icons are not even in zip files, for example:
/usr/share/icons/breeze-dark/actions/32/window-close.svg

Looks like that GTK+ have theme information in CSS files … well … there could be simpler option, but it’s not also that hard to parse it … At least there is no NIF needed:
/usr/share/themes/Breeze-Dark/gtk-3.20/gtk.css

I’m not sure how it looks like in MacOS and in Windows (in details) - it’s why I want someone to take literally full research - i.e. collect all information about vm and app theme files - their format, how to parse them, if NIF is required etc.

@ConnorRigby

Which now is done by scenic . In same way scenic is drawing in OpenGL button I want to have “advanced” button i.e. just more them options.

This is what Scenic calls primitives . More can be added relatively easily to the Scenic source, but not externally via another lib.

If we are talking about button in this case it’s component:
https://hexdocs.pm/scenic/Scenic.Component.Button.html

Yeah, it could be hard to do it from 3rd-party library, so I would like to see @boydm opinion on this. At end we can write a fork. I would strongly don’t like to, but it’s not like that all of what I have in mind is extremely hard to implement (just look about theme files - unlike what you said it’s pretty easy to use them without even need any NIF).

@ConnorRigby

again possible does not mean reasonable. This is why projects like GTK, WX, QT etc exist. You get the same behaviour on every platform, but not using native components.

Sorry, but I don’t want to wait for Windows 20 for such simple thing like Alt + mouse buttons to move/resize window quickly. If it’s possible to do awesome things which could work in any OS then it’s definitely reasonable - at least for me. I believe that @OvermindDL1 would agree as well.

@ConnorRigby

There is no such thing as “theme files” like you are describing. You must build an application that uses the native components as they were designed. IE red-cross-right-corner.png isn’t a thing that can just be looked up somewhere. You need to be in the framework it was designed in.

Well … maybe in some specific cases, but not on those I was looking for (KDE/Plasma and GTK+ as already described). Sometimes we have even SVG files with could be useful as well.

Also it’s not like that you need to understand all frameworks in the world. Sometimes you would need to write some NIFs, but it’s not like that whole world is build with binary blobs.

Of course it’s not “5 min” easy work (it’s why I created this topic), but it would definitely give us a lot of flexibility which is always good if it’s not overcomplicated.

[ConnorRigby]

Right, so you just want to reuse the static assets used to make up a UI framework, but code the logic in Elixir/Scenic? There’s no reason you couldn’t do that with Scenic how it is right now, although it would be way too much work in my opinion. You would basically be re-implementing all of a desktop environment’s native components at this point i feel like.

[Eiji]

For sure I don’t want to re-implement each component from each desktop environment (loop in loop). Instead I want to standardize it i.e. without GTKButton, KDE4Button, Plasma5Button, WindowsXPButton etc. just use one Button and based on specified configuration fetch theme information about it and convert them to Button style.

1. We start from Component or app setting
2. We are going to use (let’s call it) ThemeManager to apply its style
3. ThemeManager is using ThemeFetcher
   • current theme - fetch info about current DE, its current theme and information about them
   • local theme (if available)
   • theme from repository (like CD/DVD/USB or FTP/HTTP)
4. ThemeManager is using ThemeConverter
5. ThemeManager returns style for Component

In extremely simplified (“5 min” example):

theme_raw = ThemeFetcher.from_from_repository(@url, "theme-name")
theme_data = ThemeConvert.to_scenic_styles(:gtk3, theme_raw)
button_style = ThemeManager.button_style([:default, :visited])

@graph_with_button Components.button(graph, style: button_style)

@ConnorRigby

There’s no reason you couldn’t do that with Scenic how it is right now, (…)

I’m almost sure that scenic builtin style information is way too limited for now.

@ConnorRigby

although it would be way too much work in my opinion.

Yeah, it’s why I started to think about crowdfunding and place some job offers in order to split whole work. I’m sure that in such way we can change a lot. It’s just a matter of how much people is going to help.

@ConnorRigby

You would basically be re-implementing all of a desktop environment’s native components at this point i feel like.

Well … in scenic we are doing same, so it’s not a really big lose.

[boydm]

Hey guys. Sorry I’m late to the thread. I have GOT to remember to check this site more often.

Scenic is very strongly aimed at stand-alone devices and, as such, makes no attempt to fit into the stand OS component models. That is a conscious choice.

That doesn’t mean you couldn’t build a OS out of it, and that is effectively what you are doing when you use it in a stand-alone device. I’ve also got research code on compositing the UI from multiple apps together into a single screen, but that isn’t ready yet.

If any one wants to chat about this over the phone/video or whatever, ping me. I tend to pay more attention to twitter…

[massimo]

@Eiji

For sure I don’t want to re-implement each component from each desktop environment (loop in loop). Instead I want to standardize it i.e. without GTKButton , KDE4Button , Plasma5Button , WindowsXPButton etc. just use one Button and based on specified configuration fetch theme information about it and convert them to Button style.

Take a look at wx bindings.

What you’re trying to achieve is a lot of work (with a very big lot) that could easily take years and cost a fortune, for no real benefit

I’ve done some research work on Scenic and am working on a series of posts (and maybe videos) on using it for game development.
Simply keeping the layout coherent when resolution changes is close to a nightmare.

What Scenic brings to the table is a sane model for designing GUI applications that’s very natural in Elixir/Erlang development flow, but I think the effort of building a platform agnostic GUI framework with native looks is so big that would discourage the most passionate developer around.

Even though things like this exist…

[Eiji]

@boydm Basically I want to write some scenic-independent libraries which are looking for OS themes and rules (like <Alt> + mouse) and add support for them in scenic. So for example Scenic.Component.Button would accept map with much more than 3 fields in it. I have ~everything prepared in my mind. I just need someone to research in order to design correct structs which matches all cases (each OS/distribution/desktop environment features).

Except themes I would like to see some other changes (which at least I did not found in documentation) in scenic like terminate/2 callback for Scenic.Scene (cleanup work - just like in GenServer) or state support (also like in GenServer). Other things would be new components like Form which by default would group inputs and save their values (using default filter_event implementation).

If you want I’m almost always available here and on Slack. As said I can describe everything in details on forum if somebody is interested.

@massimo

Take a look at wx bindings.

Nope, it’s not good.

1. I did not found any Erlang/Elixir code for tray icon support
2. I did not found any Erlang/Elixir code for OS notification support
3. Predefined components in all GUI libraries are not enough

Just for example:

C++ gtkmm 3 HeaderBar and Notebook with autohide animation

Without custom OpenGL code everything is too limited for what I would like to have.

Even except those edge cases wx has nothing to my custom theme plans. I have asked about scenic just because it looks much better for me. Basically I would like to let end-user to decide which OS/distribution/desktop environment themes and behaviours he would like to have. It’s extremely important for example in Windows which adds Linux-like features after 20 years … Probably <Alt> + mouse would be there in Windows 20.

@massimo

What you’re trying to achieve is a lot of work (with a very big lot ) that could easily take years and cost a fortune, for no real benefit

Time and money? Yes, same goes to scenic itself, but this not stops developers from doing new things, right? Well … we could forgot about designing any UI, because it takes too long, but I don’t see it like that.

Also maybe you like Chrome and system default settings and accept everything even in worst form just because someone else decides to have it working like that. Lots of people are really looking for lots of customization ways in OS/apps. It has a big value. Maybe not for everyone, but it has definitely benefits.

I saw lots of topics in other languages for all UI libraries which asks about drawing custom titlebar or similar things. Do you really want to force every developer to do it alone? That would be even more time and money lose.

@massimo

I’ve done some research work on Scenic and am working on a series of posts (and maybe videos) on using it for game development.
Simply keeping the layout coherent when resolution changes is close to a nightmare.

Well … scenic is not even in 1.0.0 version. We should not require from it everything. Sure there are lots of things to change, lots of new components to implement. It’s why I want to change that.

@massimo

What Scenic brings to the table is a sane model for designing GUI applications that’s very natural in Elixir/Erlang development flow

Yeah and it’s why I prefer to do what I want in it rather than in :wx.

@massimo

but I think the effort of building a platform agnostic GUI framework with native looks is so big that would discourage the most passionate developer around.

Nice to hear that I’m special at least in this case. It’s why I would like to place some job offers to not make too many work on one developer. I have even show a level of some example job offers I have in mind, so as you can see there is something for everyone which would definitely help.

@massimo

Even though things like this exist …

Oh no … more themes and behaviours to scrape.

[massimo]

@Eiji

Nope, it’s not good.

That was the point.

Despite the effort, the number of people involved and 27 years of non stop development, it still lacks some details, because they are really hard to get right.

[Eiji]

@massimo

That was the point.

Despite the effort, the number of people involved and 27 years of non stop development, it still lacks some details, because they are really hard to get right.

Nope, I mean something else. Every GUI library is creating its own themes. Some of them allow to change them (if I remember correctly GTK+ apps could do that), but it has nothing to do with current OS theme and themes in different GUI library. It’s not like that in 27 years nobody worked on it - it’s like nobody even think about that.

Look what happens on Windows - everyone just assume that there is no way for easy custom themes and antivirus developers just draw them on their own. It’s because there is no easy option to (for example) add tabs to titlebar. There are lots of apps which are forced to write their own UI engines just because there is no such API. Again take a look at antiviruses, most popular browsers and much more apps. After that say that nobody would use that.

This is something like politics … everyone wants to have good politics, but also everyone know that there are no good politics, so nobody even think about good ones.

The solution here is to introduce something to change that rather than leave all developers alone and force them to work on OpenGL on their own.

[massimo]

@Eiji

The solution here is to introduce something to change that

besides, Elixir developers are a small fraction of the total.
Not being able to expose the library to C (or C++) won’t take you very far.
It is already possible to call OpenGL in those systems, it’s been for years.

Have you seen nanogui for example?

But it could be interesting to have a set of components for Scenic to use in custom GUIs on embedded devices.
I would start from scrollable content panels, for example.
Or texboxes that automatically wrap text.