Request for comment: the "ellipse(...)" UI paradigm

Code Sharing
1

I’ve always thought this paradigm deserved consideration.

Proposed is a UI library that is as simple to use as Codea’s ellipse(...) and rect(...) functions. I’m particularly curious what @John and @Simeon think, because they established that paradigm in the first place.

To be explicit:

  • UI elements could be created with a single statement in the draw() function
  • Their style would be controlled the same way as all other Codea shapes, by setting stroke(...) and fill(...), etc.
  • By using the same paradigms as existing Codea graphics functions, it would be easy for people to grasp

Here’s an example of how it might be done:
https://gist.github.com/DolenzSong/8b763712b687fb0d282f4c25483b0a47

(The project also includes a modest WYSIWYG feature in that the buttons can be manually positioned. It admittedly has many shortcomings, the biggest being the lack of rounded corners, but I think the principle is displayed well. This is an update of an old project, to be sure, but since UI is being discussed again, I thought it might be appropriate to bring it up.)

2

@UberGoober Basically it sounds like you’re requesting a Button class. You can create your own Button class with what you want and just add it to any of your projects that need it. Codea doesn’t need to include a lot of code to handle everything that everyone else might need for a Button. That’s what companies like Apple and Facebook do. They try to include everything that they think everyone might want and all they do is end up creating larger and larger programs that are getting slower and slower with each release. They end up consuming users limited bandwidth with each update loaded with things that aren’t needed.

3

@dave1707 A button class and a button command are quite different things, of course. The ellipse(…) paradigm explicitly eschews defining certain graphics routines as classes already.

What Codea “needs”, I think you might agree, has many possible interpretations. From a standpoint of development objectives, its needs are an ongoing negotiation between the inclinations of its developers and the requests of its users.

In other words, in one sense, it needs to be fun for people to use, and fun for TwoLivesLeft to make, and anything inside those yard-markers is fair game. I would expect that’s an uncontroversial observation.

4

@UberGoober In my opinion, a Button class and a Button command are about the same thing. It takes code to create a Button class and it takes code to create a Button command. The difference is a Button class contains only what I want it to contain, the Button command contains everything that TwoLivesLeft thinks that every user wants it to contain. I’m sure the size of the code to do each is a lot different. You may have read by now that I’m not a big fan of code that contains everything to satisfy everyone. Give me the minimum code that does what needs to be done and let me write the code to do what I want to be done. But it’s not up to me to decide what goes into Codea. I just take what they give me and do what I can with that. That’s the fun for me.

5

Surely the difference between a button command and a button class is that a button class has to be written and instantiated by the user, and a button command can simply be used by the user?

I realize I may be putting words in your mouth, so with the caveat that I am aware you said nothing specifically to this point: I believe everything you said about a button command could be levied against the ellipse command itself, too, and as such could be said to be a criticism of the ellipse paradigm altogether, not simply a criticism of the application of that paradigm to the creation of buttons.

Said another way, a criticism of a global concept is not necessarily a criticism of the specific application of that concept.

For example were I to propose, say, a “sideScroller()” command, meaning a single-line way to instantiate a side-scrolling game, your criticism might be identical, unless I miss my guess. [Incidentally, while I might be mostly on your side in that case, I’d be pretty curious how someone could pull it off!]

And I do understand that I am to some degree putting words in your mouth, and that is patently unfair, so please do correct me where I may have made a mischaracterization.

To speak for myself, my interest is in making it easier for newcomers to make cool things. I do not think it’s putting words in your mouth to say that, for you, figuring out how to create a button by hand is a welcome challenge, and part of the whole appeal of Codea. But having said that, I’d venture a guess that, for every new person to the forums who proposes a UI system, there are at minimum 10 users who will never post at all, because they gave up on Codea too soon, and quite specifically gave up because they came here to make games, not to figure out how to write touch handlers.

Not to malign touch handlers, though I think perhaps even you might agree that they are more of a pedantic pursuit than a creative one.

6

@UberGoober There’s a big difference between the ellipse command and a Button command. The ellipse is simple and needs x,y,w,h, and uses fill and a few other helper functions. For the Button command to be useable for everyone, it would need a lot more parameters and helper functions. I’m not going to create a list, but I’m sure it would be a long one to cover everything that everyone might want in a Button. As I said, I have no control over what goes into Codea, so my thoughts are just that. I’m sure TwoLivesLeft wants everyone to make suggestions and they take what they feel is doable and useable.

7

Well to my way of thinking you make accurate points about the concept of a button class that suits all needs.

It does seem, though, that what you’re arguing is not in fact an objection to the ellipse paradigm, and by extension is not an argument against my proposal.

If you take a glance at my button system, for example, you’ll see that it is far from an attempt to suit all needs.

You’ll also see that its usage is in fact simpler than ellipse(…)—all you need to give it is a string for the text to put on the button.

You may do further customization but all you need to get started is a string.

Might you agree that the ellipse command is a fairly primitive graphics element, and that it is, for the most part, only useful for beginners to Codea, and that pretty much as soon as anyone attempts a project of any sophistication they have no need for it?

In the case where you might concur with such a characterization, it could be possible to extend the same description to a button command that intentionally uses the same paradigm.

It would be a fairly primitive graphics element, really only useful for beginners to Codea, and pretty much abandoned once people attempt a project of any sophistication.

That there would be a good benefit to such a thing, just as there is a good benefit to having rudimentary graphics routines that can easily get a prototype up and running, is the core of the proposal I offer for consideration.

8

The difficulty with just having button(...) in draw is that you want something to happen when the button is touched. So for that, you need a system to handle the touches and trigger a callback. The callback, for instance, only needs to be defined once but putting it all in draw would mean that it gets redefined every refresh. And once you have interaction with touches, it gets complicated as you need to be able to delegate touch information. Only now with Craft, and even then only in the example projects, has TwoLivesLeft introduced any sort of touch handler.

Over the years there have been many UI systems developed for Codea. The fact that none have become universally accepted probably says something for the complexity of designing a system that could be used by all. While I usually am not so minimalist as @dave1707 on what Codea should contain, in this case I think he’s right. So while I encourage you to pursue your own UI system, do it for yourself rather than “for the community”.

That’s not to say that sharing ideas and “stealing” code from others isn’t a good strategy. There’s probably lots in Cider and Soda that you can use or adapt. I’ve never used them myself because I already had an extensive UI system in place long before they came on the scene. You can find it on github if you feel so inclined.

9

@LoopSpace I think it cannot be overstated that a UI system that requires the user to:

  • find and register to and search the forums
  • understand how to import and run other people’s code
  • understand how to use the dependency system in order to use it in their own code
  • in many cases understand how to troubleshoot other people’s code

…faces quite a few obstacles having nothing to do with its inherent merits.

This is why the emergence of a zygotean built-in UI system is of such interest.

10

Also, @dave1707 and @LoopSpace, while your intellectual merits speak for themselves, and as such any point you proffer deserves consideration, it does appear neither of you ran the example project I linked to.

That being the case, you each have raised issues that might be more clearly analyzed by way of demonstration than by conjecture.

11

@UberGoober I did run your program and it is an easy way to create buttons. But I don’t think a button function could cover everything an advanced button needs to do. @LoopSpace I think my minimalistic approach came from when I learned how to program. It was on a calculator that allowed 100 program steps. The variable names were the letters A to Z, there were no subroutines, and the output was the 10 digit display. Also, there wasn’t any way to save the programs, so they had to be keyed in each time from a piece of paper to run them. But it was still a lot of fun.

12

@dave1707 I am, I think, fortunate to have your objections to consider and respond to. There are a few things that doing so has made clear to me, and I hope I can reciprocally clarify.

The crux, I think, is: why is ellipse(…) useful? After all, ellipse(…) has both these flaws:

 - it is itself so limited that it cannot do anything very interesting on its own.
- using it overmuch prevents gaining the skills needed to accomplish truly compelling effects

I believe it’s not a stretch to note that these are, in substance, basically the same two objections raised to having a button(…) command: if it’s too simple it will be useless, and if people rely on it too much they won’t acquire real coding skills.

13

For the heck of it, here’s a copy of the new UI project, just jury-rigged to have ellipse(...)-like functionality:

https://gist.github.com/DolenzSong/4766112ebc5e5db8f85d5debcb0ae237

14

@UberGoober nice work and thoughts!
I have reluctancies against hiding the create / draw / touched calls all into the draw, because it is ‘not the right way’ to do it in the language structure, but i agree that your end result is very appealing. Maybe this could be useful for very quick prototyping, with some warning that for more complex programs, you must do it ‘the right way’.
It reminds me of ‘currentTouch’ vs ‘touched()’: currentTouch was very useful for me when i began, but when i started to want to make more complex projects, I stopped using it. There may be room for 2 APIs in CODEA: 1 for beginners, and 1 for advanced.
Thanks for sharing.

15

@Jmv38 thank you very much! And kudos on the coinage “reluctancies”! :slight_smile:

Your points are exactly what @dave1707’s objections made clear for me, and I agree.

All this time people have been trying to make the perfect Codea UI, but I think in fact the most “Codea-like” UI would be one that was useful but limited enough to cause you to want to write your own!

16

@UberGoober And that already exists! The parameter suite can be viewed as a useful UI for getting something working but which would encourage you to roll your own for larger projects.

But back to the ellipse vs button concept. I do still use ellipse. It does exactly what it says it does: draws an ellipse. It’s hard to break down drawing an ellipse into simpler pieces. But a button has several pieces (not just in drawing, but in what it does) which could be separated out and which one might want to do with some variations. So a button is significantly more complicated than an ellipse.

I agree with @Jmv38 about not hiding the create/draw/touch structure. I think it’s important to keep that visible, mainly because it has to interleave with other objects. In particular, using CurrentTouch is slightly dubious: if I touch the button then I probably don’t want that touch to be propagated to other objects - if all they’re doing is checking CurrentTouch then there’s no communication between them.

17

@LoopSpace, @dave1707, I feel I need to gently remind you that you are, both, exceptional.

This gives you an authority on most matters but I will suggest it may also make it hard for you to see where you lack it.

I have a particularly poor memory, as my wife will tell you. I write extremely verbose code because I have to. It is no exaggeration to say that unless I write code as plainly as I can I may not be able to understand it one day later.

I am not literally a beginner. But I feel I can claim some understanding of a beginner’s perspective, thanks to the evil elf who, every night, goes up to the chalkboard in my brain and erases 80% of it.

I feel a quite acute kinship with day-one beginners, and I think this gives me substantial insight into, and sympathy for, their dilemmas. I am never too far from them myself.