Attract maintainers #36
Comments
|
they might be interested: https://github.com/Place1/react-native-gtk |
|
They're using their fork of node-gir, and I've been having interesting conversations with them (Place1/node-gir#43) but it looks like they might continue developping their bindings. I think the best way to create some interest would be to showcase nice applications, putting an emphasis on how much simpler it is to write a Gtk application with NodeJS. Tutorials to teach how to link everything together (objects, signal, etc) would be ideal. |
|
I've already tried with both GJS and jsgtk and after cgjs and everyone told me basically Node or GTFO but when this original project was born from Jasper initial repo no-bloody-body was interested. Obvious issues about this projects:
If you compare all these issues VS Electron, since Node.js people are still mostly Web related, you realize it's easier for everyone to just deploy for electron. Me ? I can drive node.js right away from WebKitGTK through GJS and Workway so I can drive Node.js, real Node.js, through the browser, without even needing Electron. That covers my ARMv11/6/7/8 needs, any Kiosk app I'd like to do, but it leaves a hole when it comes to native Node.js Desktop apps, where this project would partially shine (all doc about Gtk is in Python and JS chaps are usually reluctant to sneak_case). Anyway, if this was installable via |
I think it works: #19 (comment)
This is in the todo list for the 1.0 release. Easy installation is a crucial part for this.
There seem to be people working around this, I'm pretty sure we could create a brew formula for this. Not sure why it was removed from there though.
Electron is easier, but people are also noticing the down sides: huge binaries (100MB min), high resource consumption. It think it's possible for us to fix our down sides. Cross-platform-ness will obviously be the hardest point :/ (Thanks for the feedback, really good points!) |
tried on my MBP and it doesn't work, maybe I am missing something in here but it's not an out-of-the-box experience (it is on my ArchLinux machine though)
We are at WebKitGTK 2.20 ... that is a jurassic one that goes nowhere. The reason brew doesn't host it anymore is because it takes forever to build and it used to fail after 1 hour of 100% CPU due always some missing patch or thing. WebKit repo ain't easy to follow for builds, and you need super fast hardware to create distributable binaries / libraries. Everything else is, more or less, available in brew and for quartz, way better experience than X version, IMO, but also limited if there's not web view. Electron is easier, and already (mostly) cross platform (IIRC it misses ARMv8 though, which is a bummer), so it's unfortunately very hard to compete, but we can try. |
actually, tried again and it just worked.
|
|
Is MacOS really a priority? |
|
that's what's most developers use (at least in the US) so it's good to have Mac devs onboard, and capable to distribute apps. Actually, Mac is more important than Linux here, since on Linux we all know how to develop some Desktop GUI in a way or another, we have many choices in general. |
Maybe all developers, not most Linux developers or most GTK developers. |
|
sorry @benwaffle but your point is, exactly? |
|
I think the point is, node bindings fo GTK would be mostly used by linux folks. Mac folks usually use native mac stuff rather than external toolkits. |
I do GJS and Gtk on Mac, homebrew is a great developer companion, and it's easy to use for everyone, nothing different from node and npm.
I do, the company gave me one, but my own laptop is ArchLinux and GNOME, so I can test on both (natively) with ease.
so far this seems to work so there's no point in not keep doing that. |
|
Cross platform developer here with a need for high quality JS bindings to GLib and time to dedicate to this. I mostly want to interact with Gstreamer, on Linux and MacOS. My initial tests are positive, though I need to get issue #74 fixed before I can progress further in my testing. I will look into fixing that tomorrow. |
|
Awesome :) |
|
I'm also interested in developing cross platform gui. |
|
Support for Windows is described here. Basically, it's bad and mostly untested, but if PyGObject can do it then we can do it. Also, we have the advantage of being able to distribute pre-built binaries if someone has the time to set everything up correctly. However, we would also need to distribute the dependencies, or to make them easily installable. Not sure how much effort will be needed here. |
|
Windows is tricky here ... even in Bash for Windows (WSL), because they don't really like Linux things reaching their GPU stack. I once wrote how it could work in there, and it did, at that time. |
|
Hey ya'll, after much research, I have decided to use |
|
I will mainly focus on |
|
I just finished replacing the https://github.com/codejamninja/react-gtk If ya'll don't mind, I think I'm going to copy your installation instructions for gtk. |
|
@codejamninja sure, this is awesome, we're lacking good projects that use |
|
@romgrk I'm working on porting my app to node gtk at the moment. It's slow , but I'll get it done. |
|
@harisvsulaiman awesome, if you need assistance don't hesitate to open an issue in this repo. |
|
Some methods are not exposed to the bindings, so it might be that. If you believe they should be present, open an issue with an example :) |
|
@romgrk I feel like a vital step in attracting contributors is making it easy to contribute. Eg, writing a |
|
Good point, do you have any suggestions of what could go in there? What would help would-be maintainers to be interested? Some effort has already been made in /doc to document how to work on the project but the C++ side is missing. |
|
Here are a few items which come to mind:
I would also take a look at other successful repositories such as Gatsby, Dev.To and FreeCodeCamp, and see how they do contribution stuff. |
Node is definitely more alive than any other JS platform. GNOME staked everything on spidermonkey-GJS, and it is not going anywhere. Even if the project get to the point of proper, and more viable GJS alternative, it will be already tremendous. |
|
Indeed. IMHO the problem here is to make this into a viable alternative to, eg electron, we need to fix the major issues, but only when we will be a viable alternative will we see interest and more contributors 😆 But yes nodejs is a better bet than GJS. Just to recap missing features to be viable:
If we have that and a few nice example projects, it would be enough to turn this into a production-usable project. |
|
@romgrk I'm working on a nice tutorial. Maybe a boilerplate as well. |
|
Cool! Send a link when you're done, we can link to it. Yes a boilerplate repository would be great. Ideally I would have liked to make react-gtk the recommended way to do a node-gtk project but I don't know what's the state of the project and haven't had enough time to investigate more. |
|
@romgrk we're getting close to having react-gtk ready (Gtk 4.0 support). |
|
One part that seems to not work (that makes react-gtk more challenging) is support for virtual functions. |
|
Supposed to, I'll take a look later today. |
|
Also, meant to ask if you're on discord? I think I sent you a request. You can join the following discord server if you want to be able to track progress on react-gtk. |
|
I don't open discord regularly enough for it to be worth it. I'm now watching the react-gtk project, if you have important PRs or releases there I'll get the notification through github. |
In order to have higher quality bindings, we need to put more work into this. More maintainers means more work. Therefore, we need to find more maintainers. (also, our bus factor is very bad)
The general strategy will be to generate noise about the project in order to get more popularity. More people seeing the project means more potential maintainers.
The text was updated successfully, but these errors were encountered: