Cider -- interface builder / code generator

Version 1.5 represents a major update of the controls and of Cider, as you can see in this video.

http://www.youtube.com/watch?v=Xvzni6WDZBY&sns=em

New features:

  • Adds new controls, such as the NotchSlider and IconButton.
  • Refactors all controls around a root Control class that provides better unity, more functionality, and reduced code size and complexity.
  • Upgrades code generation in Cider, allowing the option of generating a complete "main" file skeleton for new apps.
  • Provides access to additional control properties like text alignment and background colors.

Several things remain on the “to do” list

  • Better color picker (the one provided is pretty ugly).
  • Ability to automatically generate "forms handling" code for an interface.
  • Saving an interface as local data.
  • Improvements to textbox control.
  • Refactoring Cider code, which is getting to be pretty messy.

But all in all, I feel much happier with this version.

Cider Controls 1.5. https://gist.github.com/3927497

Cider 1.5 https://gist.github.com/3927512

Wow, that’s extremely impressive.

I’m planning to add an API to allow creation of projects and tabs directly from code. That should help your project in getting code back out.

Thanks, @Simeon. I can imagine all kinds of uses for your code-out-of-code API. It’ll certainly beat the shift, copy, shift back, paste routine.

And of course, it will inevitably lead to a self-replicating, self-correcting, ever expanding AI that consumes humanity. But hey, I bet that thing will write some neat code!

.@Mark - Interface Builder for Codea would be most excellent. Perhaps this could be added as a standard example project like Spritely.

I for one welcome our new machine overlords.

@mark very nice! I’m looking forward to have this piece of code available!

Te is great value in this; if the controls are stable, this would go a great way toward making a codea app that’s functional in nature.

@Mark, Awesome project. I’d love to play with this little toy.

First draft of the Cider interface builder & the library

Cider
https://gist.github.com/3809050

Cider Library
https://gist.github.com/3809066

The latest version on the hub (link above) includes these controls:

     label
     button
     textbox
     two-way switch
     slider
     drop menu
     multi-choice button

The library includes a few additional scraps.

Keen observers may notice that I’m “cheating,” as in the Cider tool itself isn’t actually drawing the controls, but is using a stub that approximates the appearance of each class of control. If this tool looks useful, I’m planning to go back through the control classes so that each control is subtyped from Frame (the simple rectangle container class) and each is a member of UIElement class. That should neaten up both the program and the library nicely.

Instead printing the source code in console, it should save the source code in local or project data. Thus we can have a Run button to execute the source code from the local or project data. Here is the code.

function run()
   drawdata = loadstring(readLocalData('DrawData'))
   a = drawdata()
end 

Yup, good point. I’m kind of stubbing in the copy/paste solution until @Simeon &@John get the spiffy ability to write directly to a project.

New version of Cider and controls coming up later today. Refactored controls with simple inheritance to clean up syntax, direct drawing of controls in Cider dumps the proxy controls, better looking controls overall.

Cider 1.1 source code
https://gist.github.com/3846323

Cider Controls source code
https://gist.github.com/3846331

Cider Controls replaces the old Cider Library with cleaner, more consistent elements.

Examples of the updated Cider and controls are in the new YouTube at the start of the topic.

This version still creates code via the method of placing it on screen for copy/paste. Expect that to change when writing directly to a project becomes available.

Can we get an option to do it via saveLocalData? I’m busy with something else, otherwise I’d try to stub it myself.
edit: loaded it anyway…can I get some clarity on the text box field?,currently it doesn’t seem to be editable; am I missing something?

Ah, sorry. I should have generated the keyboard function to go with text boxes, Basically, at this to you main file…

function keyboard(key)
    if txtXXX.selected then
        if key == BACKSPACE and string.len(txtXXX.text) > 0 then
            txtxXX.text = string.sub(txtXXX.text, 1, i - 1)
        else
            txtXXX.text = txtXXX.text..key
        end
    end
end

Where txtXXX is the name of your text box.

So… save to local data, how do you want it to work? For loadString support as above?

Loadstring seems to be the smartest…

i plan on creating a feature where we can do a loadstring from an http request - therefore, I can store the UI in dropbox, and when the app runs, retrieve it and cache it locally so that I don’t have to re-retrieve it.

Why?

So others can make UI’s and I can load their UI without having to DL their code!

Adding that directly into my sample project didn’t work; I don’t think that the text boxes know how to get focus yet.


Sample = class()

function setup()
-- ===================
-- Copy this code into the init function
-- ===================
txt472 = TextBox('Text Box', 44, 666.5, 174, 696.5)
txt473 = TextBox('Text Box', 99, 606, 174, 636)
end

function draw()
txt472:draw()
txt473:draw()
end

function touched(touch)
txt472:touched(touch)
txt473:touched(touch)
end

function keyboard(key)
    if txt472.selected then
        if key == BACKSPACE and string.len(txt472.text) > 0 then
            txt472.text = string.sub(txt472.text, 1, i - 1)
        else
            txt472.text = txt472.text..key
        end
    end
end

You’re right. For now, you can change the touched function so that the selected property gets set. As in

If txt472:touched(touch) then txt472.selected = true end

I’ll make the library change so the next version will take care of this without cluttering your code.

Thanks.

K, thx…sorta. Still not right…I’ll wait for your ext release.

I’m rethinking how to handle multiple text boxes. Rather than having the on/off active flag, which you have to manage, I think the way to handle this s with a pointer to the currently active text box. That way, text gets directed to a single text box, most text handling can be moved out of main, and the keyboard routine gets reduced to a little stub.

Testing it out now. When the kinks are worked out, I’ll post a revision.

It’s a great work and it would be very interesting to create at the bottom à text box where we can generate the code of the objects usée and we can copy directly to the Draw section of a Lua program