How about crowdfunding for scenic-based libraries/projects?

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.

exactly

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.

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

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.

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.

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.

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.

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…

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.

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.

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

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.

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.

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.

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

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

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.

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.

Again 100% correct - I just need access to some configuration files - not API for drawing OS 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.

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.

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

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

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

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.

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

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.

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

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.

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.