A few things confused me at the start:
By “the button to display a text” do you mean the text on the button itself? That could be more clearly stated.
Passing in the variable make_a_nicer_button as an example of setting a button action seems quite confusing to me. It sort of makes it seem like that’s an actual function the button class can perform. I would recommend a more generic name that can’t be interpreted as having something to do with the button class itself.
i’ve changed the code above according to your remarks, thanks!
@Jvm38–gee, take my advice and now I have to read the whole thing! 
So, here’s another idea to take or leave. Understanding a little better how you’ve set this up, I think you’re having the user interact separately with the Button class and the Screen class, but the Screen class actually manages all the buttons. All the mandatory commands are screen commands. Would it make sense, for the sake of simplicity, and even more for the sake of having the user understand the hierarchy you’ve created, to put the button-creation methods inside screen also?
Something like screen:button()? That functions exactly like Button()? Button then persists as a stand-alone class that all the rest of the code still works with.
That way all the mandatory commands explicitly mention the screen global, and the relationship between them is clearer. Just a thought.
yes this is quite easy to do, so if it makes things clearer it could be done.
@Jmv38, is the need for update() unavoidable? It seems like a “gotcha” that users of the library might trip over often.
Chaining the configuration commands is a cool trick! I assume you’re doing it by putting return self at the end of every configuration method?
I’ve posted my effort here http://codea.io/talk/discussion/6847/soda-gorgeous-and-powerful-gui-windowing-button-library-for-codea#latest
Using the parent to trigger child actions is a good idea I think, I do this in the Soda library.
@UberGoober yes I think it is unavoidable, you have to have hooks into the default Codea functions setup, draw, touched, keyboard, orientationChanged in order for the library to be used. With Soda, I tried to make it so that it’s just a case of adding Soda.touched(touch), Soda.keyboard(key) etc to the end of the relevant functions.
I think we’re basically on the same page, in that the various interface components that you’re suggesting here are the same as the ones I have in Soda. IMO though having to set up the buttons with lots of methods such as :set :ontap setParent etc would be much too verbose. Defining an interface would involve way too much typing! Why not use a table of keys in the constructor?
eg, my button to bring up the help page looks like this:
Soda.QueryButton{ --a button to open the help readme
parent = panel,
x = 20, y = -20,
callback = function() openURL("https://github.com/Utsira/Soda/blob/master/README.md", true) end
}
If I wanted to override the default style or shape, I add style = Soda.style.default or whatever. The only time you can’t put something in the constructor is if the callback needs to refer to the thing itself. In those cases, you can still just define the callback outside of the constructor in standard Lua dot notation, eg:
local menu = Soda.MenuButton{x = -20, y = -20} --a button to activate the above panel
menu.callback = function() panel:show(RIGHT) menu:hide(RIGHT) end --n.b. if a callback refers to self, eg here "menu:hide", the callback has to be defined outside of the {} constructor
@yojimbo2000, I think you’re thinking of the manually-added calls to draw and touched–which both you and @Jvm38 must require, of course–and I’m referring to the update() call that Jvm38’s buttons require when you manually modify their properties.
I hope you won’t mind the feedback that when you suggest that Jvm38’s approach is too verbose, and then you give an example of your own approach, yours looks the more challenging to me. The big advantage of Jvm38’s is that all his methods and parameters will be automatically exposed by Codea when you type the object names. It may be more concise to use a parameter table once you know all the parameters, but if you’re starting from zero it’s far more efficient to have a class structure that reveals itself to you automatically, through the standard Codea interface.
But all that aside–wow, Soda is gorgeous! Terrific!
@UberGoober thanks fors making that point (i thought the same, but i didnt feel easy to argue for my own choice). And Soda is great!
The big advantage of Jvm38’s is that all his methods and parameters will be automatically exposed by Codea when you type the object names.
The autocomplete doesn’t work for a project’s dependencies though (assuming that’s how these libraries are going to be used).
It’s a fair point though, that having methods for each of the settings does make the interface more explicit. I’ll have to document Soda quite a bit more if people are going to get the most out of it.