Feature Request: Prompt, Alert, and Confirm dialogs

Suggestions
1

I would love to have the equivalent of JavaScript’s prompt(),alert(),and confirm() dialog boxes in Codea. I understand why you don’t want to do general UI controls, but being able to have these three dialog types would provide a lot of utility; especially because it isn’t really possible to write a good text input field in Codea at the moment.

2

Good points. I have an alert() in the works but it’s not yet available (still thinking how to design the API for buttons and callbacks).

3

@Simeon were it me, I wouldn’t both with callbacks at all. I would pattern them after the JavaScript calls. alert() and confirm()returns true for “OK” and false for “Cancel”; prompt() returns the string entered or nil for cancel.

Technically you don’t need both alert and confirm. You can combine them with one call: messageBox(message, [okButtonName [, cancelButtonName]]) if they provide only message then you get a Close button. They can override that by provideding okButtonName. If they provide cancelButtonName, then the dialog has a second button.

So given that, then confirm()becomes:

function confirm(msg, okButtonName, cancelButtonName)
    okButtonName = okButtonName or "Yes";
    cancelButtonName = cancelButtonName or "No";

    local retVal = messageBox(msg, okButtonName, cancelButtonName);
end

And alert()becomes:

function alert(msg, okButtonName)
    okButtonName = okButtonName or "Close";

   messageBox(msg, okButtonName,);
end

And prompt() becomes its own beast but takes the same three parameters as messageBox()

But regardless of those particulars, I think just going modal and returning some king of boolean or button index is the way to go. It would be in keeping with the kind of low friction API design you are going for.

4

The problem with that is those designs are blocking calls we would have to stop executing your draw loop for the duration of the prompt.

5

@Simeon I can’t speak for others, but that is what I personally want to have happen. IE a modal dialog is a modal dialog, if you will.

I am not saying there is now value for dialogs that could run while the draw loop is operating, but for the 80/20 case blocking is just fine

6

@JockM, But couldn’t you just use paused = true to stop or paused = false to run the program? And when it comes to game design animation is apretty darn important part of the equation.

7

I don’t think these should be blocking fwiw.

8

Gideros and Corona implement a callback system whereby you pass a function (or use a closure) that is called with the result and it’s up to the programmer to structure their game logic properly to ensure you wait for a result (although granted both of those systems use a retained mode display hierarchy for their graphics).

Personally I think having just a single “draw” function is a little limiting - ideally there should be an “update” and a “draw” function to force a separation of the two.

Just my $0.02

9

thanks for 1.4, really nice! when talking about dialogs, would be nice if font-select dialogs, color picker and similar would be available in the runtime.

10

@JockM they should block interaction (modal) but I don’t think it would be good to disable draw updates for the duration of the prompt. iOS does not do this either — core animation layers are rendered during modal prompts.

11

@Simeon I personally don’t have a problem with that. It feels to me in keeping with Codea’s philosophy, which is very much 80/20.

When I ask a modal question, I expect it to have a modal effect. Were I writing a game where I might want some level of animation to continue, then I think it is fair to say that the user is more advanced and able to do something slightly more complex.

In that case, I would say it is reasonable to do the dialog in a thread and Codea would call lua_yeild() periodically while the dialog is up.

I personally think that is the best middle-ground solution. The alternative is something like this…

But if you don’t want to do it like that then:

Fair 'nuff. Then I propose something like this…

  1. You add a new callback called pause(isPaused) that tells a project if external forces are pausing the app.
  2. You set an internal paused flag as well
  3. You spin off a new thread to run the dialog. This allows draw() to continue to be called, but because of the flag touched()won’t be.
  4. When the dialog thread has its response then you pass back the response to the lua code that prompted the dialog
  5. You clear the paused flag and called the user’s pause() function

All of iOS’s UI runs in its own thread so you never have Window’s or Java’s worry about only doing UI in the main thread.

It has been a few years since I have embedded Lua in an app, but the last time I did I I found you could get away with limited reentrantcy without problem.

It would be reasonably quick to prototype, at least.

12

@ MyC0dea Indeed on could but that, but Codea is supposed to make things easier/simpler. Needing to continue drawing isn’t something everyone wants to do. Indeed it doesn’t make sense to in many/most cases. So at least to start with I would be happy if Codea introduced fully modal dialogs, and then added modless dialogs later

13

@JockM I think allowing drawing to continue would be best, and easiest, for most users. Especially for simple alerts. Interaction will be disabled automatically during the prompt (iOS will do this).

Users who want to stop animation could easily set a flag to pause animation for the duration of the prompt (though I would recommend against it, as it looks bad).

14

I just opened a small cross section of iOS games on my phone. I picked ones that used Cocoa dialogs for asking or a name, or simple yes no questions. All the ones that did paused animation.

And that makes sense, we are talking about thing that are very quickly dismissed. We aren’t (at least I am not) talking about dialogs that are going to be up for a long time.

Modeless dialogs and paused flags add more complexity to novice users. It makes it harder to write quick prototypes and get that stuff right.

Whereas if you make them modal, and make sure Codea makes sure to call lua_yeild() at apropos times, then it is quite easy to have a modal dialog that lets animation continue.

But I have no interest in making another epic thread. The request is in. To thine own self be true.

15

Hmm, I just tested it on the springboard. If you touch-and-hold to delete an app and they all wiggle, then you press the delete icon, the modal dialogue appears and the app icons continue to wiggle in the background.

This sort of behaviour would be expected by most people — I think stopping animation here would be jarring.

You should, of course, not be evaluating important logic while the user is unable to respond, but that is a design issue. I think having the draw loop continue by default allows for pleasant animations (such as Cargo-Bot’s physics based title screen) to occur while you respond to prompts.

16

It is possible to create a “Dialog Box” very easily without interfering with the animation. Look at my windowing class located at https://github.com/deamos/Codea-Window-Manager .

You could just use that on top of whatever you are normally animating without issue.

17

@Deamos That is very cool, and thank you for pointing me to it, and I will almost certainly take advantage of that code.

However part of the reason why I would like the iOS system dialogs is so that cut & paste will work, they will use iOS’s accessibility settings, etc.