LÖVE

A lot has already been said about LÖVE GUI libraries. The issue seems to have settled to multiple (unofficial) GUI libs, of which only LoveUI and LOVEly Eyes have been active lately. Both projects are maturing. They are very different from each other, with each a different design philosophy. So far, all is well.

The problem arrives, IMHO, when someone wants to make a game that uses a GUI library. Either LUI or LE is chosen, and the developer works on the project.
But after a while, he* finds it was the wrong choice for that particular game. Only now it's too late to switch without a complete rewrite. If only there were some sort of uniform interface for the GUI libs! Then the whole problem could have been avoided.

I would work on such an API, if it works, and enough of you are interested. So, what do you think?

*or she?

EDIT: Added poll. Please, tell me what you think!

Well, it sounds like a good idea, though you do need to talk about it with appleide (for everyone who doesn't know: the creator of LoveUI) and athanazio (Lovely Eyes, together with Robin himself, and somehow I'm credited...).

But on the other hand, you make a design choice, if it's wrong.. well, too bad. It's like being half-way through a game and deciding LÖVE isn't the way to go, there's no compat code either.
However, you could also see this as a matter of good programming, code abstraction is always good (well, not always, but let's skip the details).

I vote: YES!

Robin wrote:*or she?

Good question..

I placed a poll, and would like some feedback. Please, vote or reply.

I've voted. They're too different.
e.g LoveUI doesnt have stars but lovely eyes do. Whats the API for star? and if you happen to switch?
If one wants to maintain compatibility incase they realise they made the wrong choice... Bartbes is right, just abstract the code!
I've done this to a certain extent in the lib... Most calls to love.graphics are made to copied functions inside LoveUI.graphics so if the functions happen to change I dont need to use find and replace on everything.

In a game that has lots of textfields it'd probably look like:
Then if you happen to want to switch libs, all the calls to LoveUI to make textfields can stay the same and you just change the function.

Someone can make a lib to do this if they feel like it actually.

You'd go "lib.switchLib("lovelyeyes")" to change libs and everything will be switched but the addTextfield calls will stay the same.
I dont know anyone who would make something like this though; It's not the best way to express your creativity Unless they did it for their game and wants to share it.

EDIT: oops my bad, Robin said he would volunteer. =D

In Netris for example the GUI code is in seperate files from the game code, so even though it will take me some time to move over, it's not like it's nested itself deep into my game logic.

EDIT: And I voted for the ponies..

appleide wrote:e.g LoveUI doesnt have stars but lovely eyes do. Whats the API for star? and if you happen to switch?

This may indeed be a problem. I already thought about it. Mostly, I think the UGA should mainly support the common base. The most-used controls are in both libs anyway. For the other cases... I have no idea what to do about it. Not implementing them means limited functionality, implementing them means less uniformity.

On second thought, I think not adding adding them by default is a better choice. If the other lib implements it as well, I can still add it. Although, maybe the development of both libs could benefit from already having an interface to control X, before the backend is written...

Arg! I don't know.

My framework has very limited GUI functionality. I added a listbox the other day, but it was pretty much pointless. Appleide's lib is coming along nicely so by the time I have a free moment to mess with my framework some more, it should be complete enough to just adopt and use.
Rather than making a unified API for a dozen incomplete GUI libs, I'd rather just see a single complete GUI lib.

Ponies++

I think that this would just become problematic. Creating a single API structure that all GUIs must follow will only serve to stifle the potentials of the various libraries and in the end people will just circumvent the API because it doesn't serve their needs (like: "hai gys, i made this new GUI lib, but it doesn't use the standard API structure because it wouldn't allow for combo breakers" etc). I think that the solution is not to standardise the GUI libraries, but to merge them. People have to be fekking realistic when they take on the massive task of making a library and consider that maybe their great ideas could be just added to someone else's existing library. Use the power of open source to help each other make a few great libraries instead of a lot of partially completed ones.

THE MIKE HAS SPOKEN

(PS: I, too, voted for the ponies)

Very well.

Since it doesn't seem the community is that interested (and the mike has spoken): I hereby consider the UGA proposal rejected. Instead of trying to make an API for the libs*, I will put my efforts in assisting the developments of LUI and LE. Merging them will be even more impossible than making an API, I think, because they are so different. So, this means either, all but one of the projects have to be abandoned, so we can all work on the same lib, or we have to live with 2+ GUI libs. But this is up to the makers of the GUIs.

* which, to be fair, would have been a monstrous job to take care of anyway.

I ended the poll. With an overwhelming 50% plurality, the LÖVE community decided that Ponies Are Pretty.