Thanks for your reply. I've also recently noticed that 2 people are watching my github repository, which makes me think I should do some more work on it
I have to admit that I was a little worried about the lib name, but I figured "what the hell, it's asking for it"
I would say that your thoughts are pretty much spot on. I've now worked on 4 games at work, and several other attempts outside work. I've had the experience of a handful of UI systems. Some of them have been immaculately written and incredibly well documented, but only one had an editor. The editor was buggy as hell. It crashed randomly. It didn't allow for custom elements. If you gave it something even marginally wrong in the plaintext UI file, it would throw a hissyfit, often no error messages, just crash after a minute of hanging. Still, it was an improvement, much as artists couldn't technically use it because of the nuances, it made doing simple layouts much easier as you can visually see and compare to mockups. With a decent editor, you could cut out the mockups and give it directly to artists to do the layout. It's by no means necessary, if a programmer is sufficiently artistically minded, they might be doing the art themselves, in which case it usually doesn't matter if there's an editor or not.
With regard to the amount of files. I would hope that the only thing you need to include is gooey/gooey (although, I'm just learning how modules work properly, so that will hopefully become just gooey) I have yet to work out how to make the include paths relative inside the gooey module, but that's because I haven't looked into it yet. I mentioned that I also wrote a small localisation lib and included that. The reason for adding that (it's currently a requirement to use gooey) is that the gooey text parser splits on spaces. I can't, therefore, have labels with multi-word text in it currently. I thought, rather than spend an age writing a decent parser, I would just use single word localisation IDs and load the text from a csv. You can now replace Amor with another localisation system, if you desire, but eventually, I'll remove this dependency entirely.
The data files are currently split up for ease of reading. They're currently hand written (I may replace them with a binary serialised format when the editor's written, not sure) There's no reason why they couldn't be in one file but I'm planning on adding an "include" type command into the parser, so you don't have to manually load multiple data files in code. If the editor outputs plaintext, it will have one file for each UI screen/page and will hopefully group common (clonable?) elements in a separate file. If it's serialised, I don't see any reason why it would be separate files at all, but I haven't planned that so much yet.
Custom elements will be probably implemented in something like gooeyProject.lua, which will have functions like gooeyRegister() in them. The editor can then manually (using system IO rather than love) open this file and call gooeyRegister to add the custom elements to the editor, so it knows how to handle each element, and what things would be available to modifying.
Yes, that's a lot of files, but in general, all a developer needs to do is maintain the gooeyProject, include the gooey library (and amor), load a minimum of one .gooey file and do some basic hooking up (sending mouse actions for gooey for example). For an artist, they would have the editor, they would just open the project, which would automatically link in any .gooey files, so their workflow shouldn't be too difficult.
Now, moving off the first of your comments to the next one. I've found documentation to be a strange beast. It's usually the case that it's incredibly difficult to get started with, but once you start, it just flows out. I tend to work in spurts. I develop for a while, doing very little documentation, then spend the next session documenting what I've done. Technically it's better to do documentation while you go, but once I'm "in the zone" programming, trying to add documentation just feels jarring.
As an aside, I love how Lisp works, more languages should be self documenting. Might try and add something similar to the lua classes... hmmm
Finally, existing libs. I am very bad when it comes to this. There are two parts of me. One is very immature, wanting to write everything myself. One part says "if someone's already done the work, why do it again." I've been tending more towards the saner part recently, but I quite often get burnt. There are a great many great libraries out there to do more or less anything. They are very very rarely written with the same design that I would want to use. More often, they are (just about) flexible enough to use for my purposes. I've said that I've looked at other libraries. I have to admit that, much as I've looked at them, I don't know exactly how they work, so it might be possible to write an editor for them. My experience, however, shows that it's pretty difficult to create an editor for a UI system that's designed originally to be hand laid out, let alone code driven. I wouldn't have a clue where to begin with creating data for these libraries. Basically, it's far too much of a deep end for me to jump in, a new language, a new library and a new design. Making a basic UI system around my own design is easing me in more gently
Wow, I've just realised the length of the essay I've just written. Apologies for the length. Thanks again for the reply and the thoughts, I hope I've been able to answer your questions.
Decided to call that "Amor" as it wasn't taken by anything else 