I currently have some free time and looking to create a library for elixir. The thing that always hold me back is trying to come up with an idea of a library that could be truly useful in elixir, I want to avoid creating a library for the sake of it. The things I am looking for are:
The library should be lacking from elixir/erlang or must be re-implemented from the scratch: I don’t want to create an elixir wrapper for an existing erlang library or maintain an already created library;
The library should be used: this points to the thing previously mentioned, I don’t want to create a library for the sake of writing some code;
The library should make sense in elixir ecosystem: I want to avoid creating a library that would have no place in elixir ecosystem.
There is lots of place around scenic library. scenic itself focus on embedded devices, but allows to write “standard” desktop GUI applications. There are tons of topics here …
Desktop integrations - every OS/Desktop Environment (Windows, KDE/Plasma, Gnome and so on) specific things like notifications, media control, panel progress notifier, tray icon, themes, icon themes, sound themes etc.
Non-DE/OS integrations - integration for everything which is not tray, panel, window manager etc. like custom sound effects, custom app’s OS-independent and custom themed notifications, detecting the type of hardware, its temperature and so on …
from custom pickers up to office (word, excel etc.) components, equivalent to core_components in Phoenix would be amazing, ability to easily stylize app to bootstrap or other css framework could be interesting to many existing web projects as well
I even saw some simple 2D games in it, so maybe some simple game engines for easily creating card games or something like that
and literally thousands of other ideas. We don’t have much Elixir in desktop GUI and even less of those are really popular.
Why? Just for example livebook.dev - they have only Windows and Mac versions. Having a scenic-based would give us one project compilable for Windows, Mac and Linux at least.
To be fair I had plans in the past of working on scenic, and it totally went under my radar now.
I wanted to create a backend for OpenGL ES, so I could run a full render pipeline on Android. In my vision elixir and OTP are vastly superior to any development solutions currently available. gogl even tries now hard to make their shitty jvm they use on android have some fault tolerance capabilities.
The point that stopped me from investing any more time into this are gogl shady practices, they roll updates that try to tight down the usage of native binaries, even to this moment the only way to deploy and use binaries is to mask them as so libraries and symlink them at runtime.
If we take android out of the question, the next question is why would someone use scenic or a library built on top of it, instead of a library that renders a browser natively like elixir-desktop? For example the original use-case scenic is used for, on embedded devices, makes perfect sense.
Well … I think that it would be as big change as Elixir was for me. Now when I have a repeating task that I don’t want to do once and once I’m simply writing a single file tiny Elixir script (rarely close to 100 LOC). I spend on it extremely small amount of time and this is just amazing. Also even an ecto-based script is pretty simple to do as I already posted some answers with them. I would love to have something like it in scenic.
Look that in KDE/Plasma there are interesting scripts like kdialog:
{_output, status} = System.cmd("kdialog", ["--yesno", "Do you like Elixir"])
if status == 0 do
System.cmd("kdialog", ["--msgbox", "That's great! Me too!"])
end
With a bit of love we could do something like:
if MyLib.Dialog.question("Do you like Elixir", image: question_mark_img, sound: question_sound, theme: custom_theme) do
MyLib.Notify.send("That's great! Me too!", image: tada_emoji_img, sound: tada_sound, theme: :auto_detect)
end
We could either detect a current DE/OS theme or use custom. We could draw notifications or use a DE/OS one with integration. There are lots of possibilities to use such lib.
In general, interaction with OS sound like a nice idea, however the biggest question is how achievable is this cross-platform? You have Windows, Mac and linux that runs multiple desktop environments, each possibly having APIs conceptually different from each-other. The other question is the same as @lud, why not use wxwidgets that already is part of OTP, making a wrapper for wx is something I would like to avoid.
Ok, but why we should use Elixir then when languages like C++ have a strong communities and tons of libraries around wxwidgets, Qt, GTK+, WinAPI, FLTK and others? wxwidgets in erlang are only bindings. By knowing the assumptions of scenic and read Erlang -- wx the erlang binding of wxWidgets I really do not see the point of your question.
I’m definitely interested in helping out if you want some help. I also don’t really have an idea for a library since I’m fairly new to Elixir. I’ll be watching this thread.
Those are completely different topics. First of all we can easily fetch tons of data about themes and other things and use them when passing a theme option. The integrations are completely different topic. Sure, at start they are DE/OS specific and later someone would write a wrapper with %Notification{…} struct and would render only supported fields or (as an alternative option) use a custom (draw) OS-independent notifications.
The point of integrations is not having fully OS-independent app, but it’s about having an OS-independent app with an optional features enabled on runtime after detecting specific DE/OS. For example in KDE/Plasma tray icons are something completely different, but I really like the idea behind them. The developer should have ability to just create a “generic” tray icon or spend a bit more time to use library integrations and make his/her apps be more useful in specific DE/OS.
Well … If you really have no idea why not to use wxwidgets (or any other framework) in long term then let’s give a simple example … Could you please add an option in setting that let’s user choose any theme including KDE ones? Have fun trying to dynamically “convert” Linux configuration files to CSS files in different file structure.
Look in Elixir parsing a CSS and putting it’s values to struct is not a big deal. It’s even simpler for configuration files, but I really do not see an easy way to use Qt themes in GTK+ or GTK+ themes in Qt. Now think that each GUI framework have not only different engines, but also they change across versions. I do not track everything in that topic, but I can imagine that some things in GTK+ v4 are much simpler to do than in GTK+ v3. Not every theme have it’s version for all other GUI framework, but even if … Let’s say everything above is simpler than I think and everything could be done in 5 min …
Now please guide me how to write a KDE/Plasma (Qt 5 based) tray integration in wxwidgets? Most probably I would need a bindings for Qt and KDE libraries as well and “somehow” make all of them work together without any issues. Then let’s go even deeper into Debian-based system. Are they still on KDE version 3.x or did they already moved to 4.x version?
That’s why importing CSS or Linux configuration files into generic Elixir struct and pass it as an option to the library would make much more sense. Before Elixir I never dreamed that there could be a library that in “5 min” of work would allow me to make all DE/OS themes importable. Now it’s only a matter of time/work on said library. Look that even the most configurable DE does not have an option to import GTK+ themes. Having a truly DE/OS-independent apps with lots of integrations would be a killer feature for many end-users.
They often wait years before someone would fork some project and write it in other GUI framework, so it would integrate well with their DE. In practice they just take a popular theme or looks for alternative apps or as above have inconsistent look and feel for literally long years. Isn’t only theme part enough convincing? What about tons of other parts of applications that as in Elixir shouldn’t be touched by app developer as we have 10x less code in all other kind of projects.
The negative is the PDF2.0 docs have to be bought (like $300 to the org that maintains them), but the 1.7 docs are freely available.
Hexapdf’s source is OO obviously but generally alright to read, but when I looked into it, the 1.7 docs for the spec aren’t too bad just… it’s a lot.
Separately, I also wanted to do HTML to PDF that didn’t require node. I lightly looked into wrapping a rust library, like calling the Servo core libraries that power Firefox, but when I last looked a couple years ago, I couldn’t find the right place.
Ooo nice. I’ll have to take a look at it in the next few weeks. I know we were going/hoping to find a Rust library for the possibility of a tight integration that could be included as a binary, but honestly something that doesn’t require node or a headless chrome in the same container would be good enough to warrant investigation, especially if it’s less resources. We were considering running some serverless functions, or a host dedicated to an instance or 2 of browserless (https://www.browserless.io/) and using shortlived single-use tokens for authorizing it back to our endpoints. May still have to do that, actually. Batch PDF generation is a pain to have to plan your scaling around when Elixir and the BEAM are so efficient
[self-promotion] There’s also ChromicPDF which does not require Node. But it uses Chrome, so may not be of interest for you @felix-starman .
Also thanks @LostKobrakai , will look into weasyprint as well. I’m generally a bit sceptical of tools that claim to convert HTML+CSS to PDF (or any other format, for that matter) and don’t use a full rendering engine, given the complexity of these things. But it looks promising nonetheless.
You certainly have a good point about limitations of wxwidgets. The only concern I see with all of this is real world usage, do we actually need these kind of features for 99% of the applications? We use the browser for most of applications nowadays, and it seems more than sufficient for the needs, what could be gained from having a native integration with a DE/OS?
It would be interesting to have Elixir target a different runtime. It’s mostly a nice-to-have though, as Phoenix Hooks are more than plenty to get the job done. The main argument here would be that you could write more portable Elixir while avoiding Javascript. It’s purely developer experience.
Then you could define JS hooks right within the same module that it is used, and somehow extract the function to compile into JS to serve.
One could define a DOM module and other things to interface with JS, just like Elm. And port over the standard library, maybe make JS immutable by default, etc.
It’s an amusing thought, but probably impractical to go about and may add unnecessary complexity compared to just using JS.
“Yeah”, we write thousands of local Phoenix servers just for creating apps with access to local drive … Sorry, but I really do not understand your point.
Do we have even 1% of web applications that have native app look each having an awesome browser extension that integrates with DE/OS? I don’t know even one. There is a generic KDE/Plasma browser integration for example for multimedia handling, but still such integration is just like a drop in the ocean.
Also with such argument why we are developing? There is a Google, it’s used by most people and there is no need to have other one, right? I don’t think so … “Smart” algorithms (that causes more problems than helps for me) based on all around spying. I would like to write lots of tiny pet projects that are not Phoenix servers, do not require a CSS framework (which does not integrates with theme of my DE/OS) or spend lots of time to style everything on my own in CSS.
And once again, regardless of we ask for wxwidgets or web apps … What about Elixir part? My proposal was to have GUI in Elixir. Not with C/C++ bindings, not with CSS/JavaScript, but Elixir that have every component as separate process, that have 10x less LOC, …
Honestly I really don’t like when people tries to force using web apps to everything even when those completely does not Also I don’t like starting too much servers on different ports. Maintain such an environment is like a hell. I either need to have a terminal in background for each app just to press Ctrl+C or kill a process that’s not currently on any terminal. Similarly having many browser tabs for a sake of having app in background is like a bad joke. I honestly prefer a native app, with ability to minimize or “close to tray” option. For many such things web apps are extremely uncomfortable.
