Proposal: Include love-nuklear as a Native GUI Framework

[slime73]

Original report by Landon “Karai” Manning (Bitbucket: karai17, GitHub: karai17).

---

While I am aware that LOVE follows the general principles of Lua in that we don't want to bloat the API with cruft, I believe that one feature severely missing from LOVE is a native GUI module. There have been several attempts to make various GUI frameworks for love, all of which fall flat (including my own). I've been tinkering around with love-nuklear recently and it feels like a strong contender for something that could be included natively with LOVE. nuklear itself is an ANSI C header-only library and love-nuklear is a pretty decent Lua binding for it.

I really think LOVE could use a native GUI module, it would help round off all the major features in a framework that we already have, such as networking and physics. I'm not necessarily looking for a fast decision here, but perhaps we could discuss this?

[slime73]

Original comment by Gianmichele Mariani (Bitbucket: gianmichelemariani, GitHub: gianmichelemariani).

---

I’m thinking from a basic user pov. You want them to get LÖVE source and plugins and put them together with minimal effort. At the moment some modules/plugins require changes in the source in various places, they are not really self contained.

Defold for example has a very good extension system.
https://defold.com/manuals/extensions/

Not looking at building custom engines in the cloud like they do, but the extensions look self contained, without changes needed to the main core.
I think this can favour this small extension being built and maintaned by others, without shifting focus for you for this requests (GUIs, ads, mobile services, etc)

‌

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

At the moment some modules/plugins require changes in the source in various places

Which places? I don’t think I’ve seen that before.

[slime73]

Original comment by Gianmichele Mariani (Bitbucket: gianmichelemariani, GitHub: gianmichelemariani).

---

Don’t we need something in boot.lua for example?

I was looking at this:

https://bitbucket.org/bio1712/love2d-admob-ios/src/master/src/

I know the author had difficulties creating callbacks. I think he mentioed that is polling every second.

Apologies I’m not the strongest at native code.

‌

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

It looks like there’s code there to automatically call a function every frame so users of the ad API don’t have to call checkForAdsCallbacks() every frame themselves, but it could probably be changed to push events to love.event instead (which would avoid modifying love.run), or just require users to call that checkForAds function. As-is, anyone with a custom love.run would have to update theirs to work with that ad API, which doesn’t seem ideal to me.

[slime73]

Original comment by Gianmichele Mariani (Bitbucket: gianmichelemariani, GitHub: gianmichelemariani).

---

Right. This is why from time to time I keep pestering you with this more official way to plug modules :)

Anyway, sorry I’ve been derailing this thread too much.

‌

‌

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

Regarding my above observation about their modified boot.lua, I meant that I can think of a couple ways to implement what they do in that file without requiring anything extra to change in love’s source (so I think that’s not a good example of something that requires a source change to be a pluggable module - for boot.lua at least)

‌

This is getting wildly off-topic but I want to clarify - I’m not against improving the native code ecosystem for love, but it’s really important to first understand what real problems people are having with how it currently works (and what problems people are having that are just them either not knowing about a feature or trying to twist love into something more specific to their native library rather than making something more idiomatic), and maybe even more importantly, the problems specific proposed solutions would introduce and how they balance against the problems that are solved by that solution.

Everything also needs to be thought of within the context of the platforms love supports and how it supports them. For example, it is not actually a good idea to use cmake on all platforms, so some sort of solution that only works when cmake is used isn’t really useful. Also, compiling and sharing a built binary for love on some platforms like linux is not as simple as just downloading the code and pressing compile, because just doing that is going to make it incompatible with older operating systems if you plan to share that binary. love also doesn’t have the backing of a major company like Defold does, so realistically we can’t provide easy on-demand automatic cloud builds for all platforms any time someone wants to add to native code.

‌