Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

My Codea Suggestions Page

13»

Comments

  • Posts: 2,820

    I just had a fun thought:
    Dapp + Codea = App apple would reject at firt look.
    I'll keep dreaming.

  • Posts: 2,820

    Haha. 102 (now 103) comments.

  • BortelsBortels Mod
    Posts: 1,557

    TLL are doing just that - they had to remove .codea import, but they're putting it back, so it can get formally rejected and go thru the appeals process. Presumably when there's progress, you'll see it on the "new versions" sticky thread at the top of the forum.

    re. javascript and mobile safari don't have those restrictions - an excellent point, that's been made often to little effect. Apple apparently believes the javascript sandbox is secure enough to allow unaudited code to run - and cannot say the same of Codea's lua stuff. My response there to Apple is "you have the source, go look!", but Apple... Apple is Apple. They do what they want.

  • Posts: 2,820

    They are too large to care. Ya I know about removing the .codea file. Sad. Makes me cry... Almost. Is there somewhere I can email apple and complain (or in other words make suggestions?). I know you can only do it with iWork for Mac. That's it.

  • BortelsBortels Mod
    Posts: 1,557

    No place that does any good.

    I'm looking at the nook, jailbroken - it's not horrible. smaller screen, but nearly the same resolution, so the dot-pitch is a bit sharper. Just considering options should Apple keep it's head stuck where a head ought not to be.

  • Posts: 2,820

    AHHG! NO! I HAD TO WASH MY EYES OUT AFTER USING ONE!

  • Posts: 2,820

    YIPEE! Apple might allow iTune's Sharing code export. @John mentioned that GLSL Studio has iTunes code sharing. He said so here. I'm desperate for code sharing. Aren't I.

  • edited January 2012 Posts: 2,820

    Bah Humbug (It's a little late). I guess it might just be because it's GLSL code.
    25. GLSL code included.

  • BortelsBortels Mod
    Posts: 1,557

    GLSL code is a largely different beast - it's scope is extremely limited, especially concerning I/O. I'd be hard pressed to even imagine a scenario where GLSL could be used for nefarious purposes... other than perhaps a prank, and even that's pushing it.

    I'll be blunt - Give me Lua, Give me sockets, and I can do some bad things if I wanted. Give me load() and text, and a free player, and I can do worse. But - you can say the same things about Fire, or steel, or indeed a text document. And while they can be used for bad, they can also be a force for awesome. Things should not be prohibited on potential harm - instead, you have to weigh that potential harm against the very real harm done by limiting freedom.

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,363

    GLSL could be used to crash the graphics driver, attempt to corrupt graphics memory, attempt to bypass the sandbox through exploits in the driver. It can do things at a much lower level since it's run on the hardware, has no memory protection, and so on.

    The Lua interpreter is limited to doing exactly what any other .app is able to do within the public APIs, making it a much better known quantity.

    (Edit: that's not to say I'm against GLSL, I think it's fine security-wise. I can just see how it could be an area of caution for Apple.)

  • Posts: 622

    There's a way to have those things and still reduce potential harm. Microsoft's virus prone operating systems and apps show a decades long determination to be "seat belt optional" as a default.

  • Posts: 2,820

    I know what bad things you can do... Pretty bad. >-) . But see what Simeon said right after John.

  • Posts: 1,255

    Obviously, any application that allows content production represents something of a challenge to Apple's walled garden. They can limit the raciness of books distributed through iTunes, but that wouldn't stop distribution of unacceptable material as Pages files. Hence the age restriction warning on just about anything that can access the web or read a file. Content creation tools also represent something of a security risk, as users could potentially overwrite memory in a way that compromises the system (which is possible in any app, but it's a lot easier to test the possibilities of something as locked down as a game when compared to iMovie).

    Codea has such a wealth of potential behavior that I can understand Apple being nervous, but really, the potential risk with project sharing and without project sharing is very nearly the same.

  • BortelsBortels Mod
    Posts: 1,557

    But there's a big difference here - you're not getting .codea files from the App store. In that respect, they're the same as an iwork document, not iwork itself (or, indeed, the same as a web page and mobile sarari). The walled garden includes the tool, not the things people can create with that tool. The mismatch here is that Apple wants to pretend it owns the right to police all code - and it doesn't, clearly, if only because I can make javascript that does whatever I want.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    I think the policies simply weren't written with coding apps in mind. Now human reviewers have to apply these policies to coding apps. Hopefully more coding apps will trigger a change in policy.

  • Posts: 2,820

    I hope the same tht apple will update their policies, unless they crack down on these apps... I have dreams of Codea being coded with no limits from apple. Oh well, I'll keep wishing.

  • Posts: 622

    Due to Codea's popularity I have blind faith that Apple will be a bit more flexible. I believe that will be contingent on Codea leaning toward staying an SDK. Once everyone is on the same page at could see Apple featuring Codea and using the agreement as an example to other apps for the "code anywhere revolution"

  • edited January 2012 Posts: 2,820

    Interesting point @Ipda41001 . But also with all the plenty coding apps on the Mac App store that aren't website making (only Xcode), who knows where apple is going. I would love to contact apple about this. X(
    Update:
    And I guess code runner and a few other.

  • Posts: 88

    Again regarding library: it would be highly beneficial having the possibility to load a lib file into a project. As both Ruilov and Andrew say, any correction of a lib file today requires several other projects to be corrected in addition. If TLL could provide such feature that would be simply perfect.

  • edited January 2012 Posts: 2,820

    Yay! I knocked some more off my list! Thank you TLL!
    19. Add more keyboard features. For instance, you would do something like this:

    UIKeyBoardType(UIKeyboardTypeDefault/UIKeyboardTypeASCIICapable/UIKeyboardTypeNumbersAndPunctuation/UIKeyboardTypeURL/UIKeyboardTypeNumberPad/UIKeyboardTypePhonePad/UIKeyboardTypeNamePhonePad/UIKeyboardTypeEmailAddress/UIKeyboardTypeDecimalPad/UIKeyboardTypeTwitter/UIKeyboardTypeAlphabet)
    
    UIKeyboardReturnKeyType(UIReturnKeyDefault/UIReturnKeyGo/UIReturnKeyGoogle/UIReturnKeyJoin/UIReturnKeyNext/UIReturnKeyRoute/UIReturnKeySearch/UIReturnKeySend/UIReturnKeyYahoo/UIReturnKeyDone/UIReturnKeyEmergencyCall)
    

    Also add the variable topOfKeyboard() which returns the point on the y axis at which the top of the keyboard sits.
    20. Add these functions:

    OpenEmail(emailadress, subject, body)
    OpenURL(URL)
    
  • Posts: 2,820

    It's really reorganized, so you might want to check it out.

  • Posts: 40

    @jlslate that's great lol

  • Posts: 2,820

    Next up:
    28. Add variable = getPhoto() which pulls up the photo chooser and set the variable to that photo.

Sign In or Register to comment.