Quick Links: Gideros Home | Download Gideros | Developer Guide
Using Wax for easy access to Objective-C under IOS Gideros
  • bowerandybowerandy +1 -1 (+14 / -1 )
    Guru
    Folks,

    Over the last day or so, I've put some effort into getting the Wax Lua-ObjectiveC bridge working under Gideros. Wax is a project by Corey Johnson that allows one to effectively write ObjC code in Lua and gain access to virtually all of the IOS libraries.

    Here's an example in Lua of putting up a native multiline text field that can be edited with the IOS keyboard:

    local font=UIFont:boldSystemFontOfSize(24)
    local textField=UITextView:initWithFrame(CGRect(50, 50, 200, 40))
    textField:setFont(font)
    textField:setTextColor(UIColor:whiteColor())
    textField:setBackgroundColor(UIColor:clearColor())
    getRootViewController():view():addSubview(textField)

    I've implemented Wax as a plugin, called BhWax, which just might be the last Gideros plugin you'll ever need to write (if you're on IOS). Sadly, Wax is tied to Objective-C for reasons that I discuss on my blog, so Gideros users developing for Android won't be able to make use of it, I'm afraid.

    Here is a short video showing how you can set up the plugin in the GiderosIOSPlayer and a peek at the demo program I've included with the download:


    More information is available on my blog page for those who are interested. I don't know whether it's just me but this seems really cool.

    Best regards
  • Terrific job man! Looks very interesting. I think it will be very useful!

    (But I don't have time to try it so soon, been hell busy)
  • TheOddLinguist +1 -1 (+1 / -0 )
    Member
    Very exciting, indeed. I think this is a nice compromise alongside the plugin system. The plugins can provide a cleaner interface within your app, but Wax will give not only more power, but relatively effortless access to some powerful libraries. I see fantastic use cases for both, and this is exciting news. If only I had a better grasp of Obj-C. hehe Very well done.

    Likes: atilim

  • I only wish something like that would be available to Android too
  • atilimatilim +1 -1
    Maintainer
    Legendary! Now I can barely sit down... :)

  • It would seem like so. At least it would allow to skip JNI step in plugin creation. Need to test it more. Which lua version does Gideros use?
  • Looks like another breakthrough step for Gideros. Nice work @bowerandy.

    @ar2sawseen
    gorkem said:

    June 23
    We use Lua 5.1.4, and no plans for Lua 5.2 yet.


    Source
    twitter@TheWindApps Artful applications : The Wind Forest. #art #japan #apps
  • =D> =D> =D> =D>


    ^:)^ ^:)^ ^:)^ ^:)^ ^:)^

    Speed of Gideros, power of native iOS = WIN WIN WIN for indie developer! :) :) :)
    WhiteTree Games - Home, home on the web, where the bits and bytes they do play!
    #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
  • Also finding same bridge for Javascript would be awesome, cause I could map Gideros classes to canvas object and allow running Gideros apps on websites through HTML5 canvas. :)

    OR

    It could work both ways and you could develop Gideros mobile apps using Javascript :)
  • :O

    ^:)^ ^:)^ ^:)^

    @bowerandy wow!

    @all Gideros Rulez!
    TNT ENGiNE for Gideors Studio - Particle Engine, Virtual Pad, Animator Studio, Collision Engine - DOWNLOAD NOW !!! IT'S FREE!!! -
    www.tntengine.com
  • awesome ^:)^
  • I've had a quick look at the video and must say it's stunning work you have done here!

    The only thing to adapt, is the class system of wax. If this would match the class system of Gideros, it would look like native Gideros Plugin System.
    (e.g. Classname = Core.class(Parentclass) )

    great! ^:)^
    Owltwins. Smart design and creative code.
    »Gideros Illustrator« - [svg|xml] scene designer using Adobe Illustrator®™ Within one line of code!
  • @bowerandy, that video is amazing, this is (I am sure) only the start of a lot of things coming to Gideros. You have always pushed the limits of Gideros with amazing results.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • ...and

    not 100% sure, but I recollect using things like

    UIImage:imageWithContentsOfFile_pathForResource_ofType(nil, "image", "png")
    or
    UIImage:imageNamed("image.png"):CGImage()

    with wax, but it spawns an error with your library, is there some change or is it something that I might be overlooking?

    Images loaded via Gideros Bitmap have a lower z-order than those of the UIKit elements and rightly so because the native Gideros elements are drawn on the OpenGL Surface where as the others are all added above this layer/surface. So any ideas?

    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • techdojotechdojo +1 -1 (+4 / -0 )
    Guru
    I got the demo working yesterday by following the instructions in the video and rebuilding the player (I have a separate player build just for Wax) however it was a bit fiddly and I can imagine it'll be a ball-ache to have to keep doing it every time you export a new project.

    So...

    Given that this is the mother of all plugin's to end all other plugin's I'd like to formally request @Atilim work with @Bowerandy to make this part of the official Gideros distribution so that the player and exported projects already have this functionality built it.

    WhiteTree Games - Home, home on the web, where the bits and bytes they do play!
    #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
  • The reason why I had never tried wax is writing so long API without code autocomplete
    feature is a nightmare for me, who can remember the detail for every api.
    Any handy editor available?
  • bowerandybowerandy +1 -1 (+1 / -0 )
    Guru
    OZApps said:

    UIAlertView:initWithTitle_message_delegate("title", "message", nil)
    or
    UIImage:imageWithContentsOfFile_pathForResource_ofType(nil, "image", "png")
    or
    UIImage:imageNamed("image.png"):CGImage()

    with wax, but it spawns an error with your library, is there some change or is it something that I might be overlooking?


    The alert view issue is caused by your use of an incorrect method selector. Looking at the Apple docs for UIAlertView, the correct one is: initWithTitle:message:delegate:cancelButtonTitle:otherButtonTitles:. So, if you create your alert with the following Lua, everything works okay:

    local alert=UIAlertView:initWithTitle_message_delegate_cancelButtonTitle_otherButtonTitles("title", "message", nil, "ok", nil)
    alert:show()

    Actually, that method seems to have some sort of vararg ... at the end to add additional buttons. I'm not sure how (or if) Wax handles varargs so I just pass nil here. You could use addButtonWithTitle: to add more buttons if you wish.

    The first UIImage call also seems to have an incorrect selector (at least I couldn't see it in the Apple docs). You can simply use imageWithContentOfFile: providing you pass a full path to the image. You need to remember that Gideros keeps its resource files in their specially named |R| folder. In order to get to the full path easily I've added a helper function, getPathForFile(), to BhWax.mm. So now you can call:

    local image1=UIImage:imageWithContentsOfFile(getPathForFile("|R|Images/YouTube.png"))
    print(image1)

    This seems to work. You can pull a new version of BhWax from GitHub that includes this addition.

    Unfortunately, doing the same with imageNamed: doesn't appear to work.

    local image2=UIImage:imageNamed(getPathForFile("|R|Images/YouTube.png"))
    print(image2)

    This prints nil. I suspect this is because the docs say: "If this is the first time the image is being loaded, the method looks for an image with the specified name in the application’s main bundle.". Since our image isn't from the application bundle maybe this fails?

    OZApps said:

    Images loaded via Gideros Bitmap have a lower z-order than those of the UIKit elements and rightly so because the native Gideros elements are drawn on the OpenGL Surface where as the others are all added above this layer/surface. So any ideas?


    I don't think there's much we can do about this really.

    best regards

    Likes: OZApps

  • bowerandybowerandy +1 -1 (+1 / -0 )
    Guru
    techdojo said:

    however it was a bit fiddly and I can imagine it'll be a ball-ache to have to keep doing it every time you export a new project.


    I've done it several times now and it gets a lot easier every time. Obviously, you only have to do it once for every NEW project and then again every time Gideros release a new version. In between times you can just tick "assets only" when you export your project. But I'm sure you knew that :)

    An alternative would be if someone could explain to me how to build all those source files into a static library in Xcode. That way only one file would need to be dragged across.

    techdojo said:

    Given that this is the mother of all plugin's to end all other plugin's I'd like to formally request @Atilim work with @Bowerandy to make this part of the official Gideros distribution so that the player and exported projects already have this functionality built it.


    I'd be perfectly happy with this. Doing this would also mean we could generate the autocomplete information for all common Cocoa classes and have the Gideros editor have these built in too. Shouldn't be too hard to write a bit of Lua reflect over all the apis and output the appropriate stuff.

    best regards

    Likes: techdojo

  • Clever as this is, if you're just developing for iOS and you're having to know the Objective-C calls anyway (understandably), why would you use Gideros at all? Leverage something like cocos2d if you want a higher level library (which offers a lot more functionality than Gideros) and develop natively. You're basically having to learn the Apple APIs anyway.

    I must be missing something here!
  • For me:

    "speed" of development, ease of use provided by Gideros (scripting, wifi deployment, lightweight emulator) that someone like me can hardly run away.
    (And I'm happy that my game designer and artist can easily build, experiment, and change game parameters, art themselves to check the result instantly on their Windows machine)

    Only when you have some need that isn't available yet, then this will come into help.

    I think that's the point (okay, at least just for me) :)
  • @phongtt Certainly speed of development in Gideros *can* be quicker but it can also be slower and more frustrating if things aren't covered (you know masks, clipping etc. etc.). But speed really isn't everything - making things too quick develop can lead to shoddy development. I just look at the quality of some of what's been released with these 3rd party systems and it makes me shudder. Apple isn't tough enough on quality control.

    In terms of wifi deployment, it's really not much quicker than having your device connected and pushing to the device in XCode (and you get much better debugging).

    I see so much here that's really centered on iOS and it's always puzzled me. And this bridge just exacerbates that, because you're basically having to learn the APIs anyway and the more things like this gets used the more users of Gideros tie themselves to iOS only. I guess that's my point.

    Not to take away from what's been done here by @bowerandy at all, which I think is a great example of pushing the system, I just think I have a different mindset after having previously developed just for iOS - I want to target all the platforms I can without having to port and maintain multiple code-bases. Not doing that seems like a wasted time investment these days. Unfortunately to do that you need to find a system that provides most of what you want, which I think I have now.
  • Okay, it will be forever to discuss/argue about Gideros being better or so for different tastes or different needs, etc.

    But I agree with your point regarding equal support for both iOS and Android (which you used to push and shout for in other threads)
  • @moopf, but surely a system that provides "most" of what you want is worse than useless! You need to be able to get around any roadblocks that you come across and have the confidence from the outset that you can do this. Gideros gives this confidence with plugins but, frankly, they are a pain to write and you have to muck around with XCode (on iOS of course) etc. The Wax stuff just makes it much simpler to do this on iOS and to debug it when you need to.

    True, if your main focus is portability then Wax gives you nothing. I can see that, for you, this is all meaningless. For me, and maybe some others, I have little interest in Android at the moment and just want to produce the best possible app I can for the iOS market. To do this I sometimes need access to native features which aren't supported directly in Gideros out of the box (turn based game kit for example). Wax gives this without the pain of writing a plugin.

    The point isn't really to code everything in Wax. You could do that and it might be interesting but, in the end, you'd probably just create something that was slower and harder to maintain than using raw Cocoa (although being able to ignore all that XCode malarky might be very compelling). No, I think the real point is to write 2D graphics apps in Gideros but drop down to Cocoa when something gets in the way.

    By way of an example, I'm writing a simple game app (my first) which isn't that complex really but even with this I have so far I've needed to drop into plugins on several occasions:

    1) To access the Photo Library
    2) To take a snapshot of the screen and save to PNG so it can be reloaded in Gideros
    3) To create a native Keyboard with editable text field
    4) To use the Turn Based game kit
    5) To create an AI module because Lua wasn't fast enough

    All but 5) I could have done in Gideros using Wax and it would be (much) faster and more maintainable.

    best regards
  • bowerandybowerandy +1 -1 (+3 / -0 )
    Guru
    @phongtt, interestingly I think that Wax *will* help Gideros to provide better cross platform capability.

    Imagine the time that @atilim has spent creating the GameKit plugin or the StoreKIt plugin and the iAd plugin. All of these things, and more, can now be done easily by us users rather than Gideros. This leaves the crew more time to concentrate on other enhancements like portability (and async texture loading; hint, hint)

    best regards
  • @bowerandy Thanks for explaining your rationale for this, I can see where you're coming from (and others) and that's cool.
  • @Andy, Maybe you might also want to add that if anyone wanted to use additional frameworks like the new Twitter Interface in iOS they could use that by instantiating a new TWTweetComposeViewController. However I also believe that the plugins might need to have the includes or is there an easier way to integrate this functionality without recompiling everything into the player?

    And I do agree and wanted to add that Gideros like other frameworks is an OpenGL based framework it offers features for Game Making, the whole purpose of Plug-Ins was to have features that were not yet included. The majority of these were to have functionality like the native widgets. Wax is not a silver bullet, but it does for a lot of developers that want to focus on iOS only provide complete access to the latest features of iOS that no other Lua based framework could offer. So in that regards, this is a welcome feature and yes, if cross-platform is the focus, then this is not much helpful.

    However if one wants to make business apps with iOS functionality, this is THE plug-in to have, it is as stable or unstable as the wrapper itself (Wax).
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • I used Wax around late 2009 but who could have thought of using Wax for integrating with a Lua based framework. It is almost like having a translator for an native English speaking person. Sometimes it is important and very useful. Thanks Andy.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • Dale +1 -1 (+1 / -0 )
    Member
    This just blows me away. Possibly the plugin to end all plugins.

    If you were finding a need for a plugin, more than likely this Wax plugin would let you do what you want, from Lua, more easily, and quite efficiently.

    It also makes Gideros, oddly, a great platform for developing LUA native-GUI iOS apps... It's awesome having wax abilities from within the rapid development cycle the on-device player, and none (well, fewer) of the setup hassle of raw Wax.

    Very excited to see this, I expect to use it a lot.

    Likes: SatheeshJM

  • @bowerandy Thanks for your work on this. Very exciting.

    It looks like Wax from Corey Johnson hasn't been worked in a few years. Is there an issue of it needing to be updated, for example for iOS6?

    How do you think the speed difference (in app responsiveness) of using the Wax framework vs MHUikit.mm?
  • @scurvyrat, yes you're right but he does still seem to answer questions in the Google group for Wax.

    There may be issues with future versions of IOS, we'll have to see. I already came across one such problem with blocks, which obviously weren't around when Wax was first developed. I think I have a solution for this in the pipeline though.

    Since the UIKit is really just wrapping UI objects and not doing much processing in between, I doubt there's much difference between using Wax and UIKit, speed-wise. I'd prefer to use Wax, I guess, because if anything is missing it can be added straight off in Lua.

    I would guess that as soon as you start looping through thousands of objects, things will probably go a lot slower, though.

    Best regards
  • Sorry did not want to hijack thread, but don't want to create a new one for such a small issue, but if anyone is interested, then it might be possible to use Scripting Layer for Android, which would work as generic plugin for Android in Gideros.

    http://code.google.com/p/android-scripting/

    Basically it creates a server and then provides android API through lua socket.

    https://groups.google.com/forum/?fromgroups=#!topic/android-scripting/sJuM2NgT2iw

    I don't really have time to experiment with it more right now, but I just thought to post it if someone can't wait and want to experiment on their own before I get the time to do it. ;)
  • Dale +1 -1 (+2 / -0 )
    Member
    @bowerandy - a few comments

    Again, I love this wav plugin, and think it could mean huge things for Gideros.

    Right now, with this plugin, Gideros may have the most rapid development environment for iOS native GUI apps. If I add a new native button, click Run, and my new native button appears instantly.

    Compare that to Appcelerator, for example, where you have to rebuild (which for me, takes the better part of a minute).

    Even with bare XCode, you're looking several seconds before the build is finished and the app is relaunched on the simulator. (Similarly, with bare wax, you have to rebuild/relaunch your app with every change, a bit slower than XCode alone.)

    With Gideros/wax and the player, UI elements can be added and changes viewed instantly. Does anyone else offer this speed of development/test?

    A few suggestions, to keep the momentum going:

    The demo app fails in the simulator; I changed the iPad detection (IosImagePicker.lua, line 43) to:
    	return 1 == string.find(model, "iPad")


    and things now work properly in the simulator. (It was trying the iPhone picker by mistake, when using the iPad emulator.)

    Also, I might suggest perhaps doing up two example apps with this:

    - UIKit demo - Do a version of the test project that does the same thing (buttons, webview, etc.) to show how the common UI elements are used, but from wax rather than UIKit. (Maybe their tableview example, too.)

    - One of the getting started tutorials, http://mobile.tutsplus.com/tutorials/iphone/iphone-wax-part-2/ would be interesting if tweaked to work with Gideros/wax.

    I assume for the latter, we ignore the AppDelegate.lua stuff and use getRootViewController() instead.

    Finally, I don't suppose there's a way to have errors passed back to Gideros Studio, rather than crashing the player?

    Again, great work!

    -d

    Likes: atilim, bowerandy

  • @Dale, I have an article that kind of attempts to address the exact issue that you have mentioned, you can read up on http://howto.oz-apps.com/2012/09/get-developing-for-free-enterprise.html There will be a couple of follow up articles that will discuss how to use the other common UI elements. However this should still be a good starting point to try and base other elements off.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • @ar2rsawseen, have you seen this? https://github.com/mkottman/AndroLua
    This is perhaps the Android version of Wax, so all Android users can rejoice and perhaps use this.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • gorkemgorkem +1 -1
    Maintainer
    dale said:

    With Gideros/wax and the player, UI elements can be added and changes viewed instantly. Does anyone else offer this speed of development/test?



    I'm seriously wondering this - anyone has a clue about how other potential fast mobile application developers do it? Are there any other (faster) solutions in this world for instant app development?
  • Not sure how relevant it is but I've been looking at Interface HD (http://appshopper.com/productivity/interface-hd) which is an iPad (and iPhone) app mockup tool where you literally create your app by dragging and dropping the widget components onto a screen and changing the options visually.

    Once done you can export your app as an xCode project and "apparently" it just compiles and will run - obviously you have to wire up the logic and the back end but it seems right up there with the RAD tools you get with Visual Studio
    WhiteTree Games - Home, home on the web, where the bits and bytes they do play!
    #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
  • @techdojo, Interface is the latest offering, there were earlier offerings from several other developers (funnily from the Australasia region or more specifically from the Australia-New Zealand region) that did generate code.

    I am attempting to write one that would do something similar and (maybe being over ambitious) also generate code for several frameworks including Gideros. The real killer is that I have to either write it thrice for Windows, Mac OS X and *nix or use something that compiles multi-platform. I was hoping to get a Desktop compiler from one of the Lua frameworks (Löve is desktop but not usable as yet in regards to protecting the source code and using native widgets) I guess I am getting a bit off topic, so... yeah, hope that we can have something like that for Gideros soon. While I am working on it, any body else wants to help, compete? welcome... ;)
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • Dale said:

    @bowerandy - a few comments

    The demo app fails in the simulator; I changed the iPad detection (IosImagePicker.lua, line 43) to:

    	return 1 == string.find(model, "iPad")

    and things now work properly in the simulator. (It was trying the iPhone picker by mistake, when using the iPad emulator.)

    Also, I might suggest perhaps doing up two example apps with this:

    - UIKit demo - Do a version of the test project that does the same thing (buttons, webview, etc.) to show how the common UI elements are used, but from wax rather than UIKit. (Maybe their tableview example, too.)

    - One of the getting started tutorials, http://mobile.tutsplus.com/tutorials/iphone/iphone-wax-part-2/ would be interesting if tweaked to work with Gideros/wax.

    I assume for the latter, we ignore the AppDelegate.lua stuff and use getRootViewController() instead.

    Finally, I don't suppose there's a way to have errors passed back to Gideros Studio, rather than crashing the player?

    Ok, thanks for that fix. I pushed it to GitHub.

    Re: the demos. I'm currently writing a turn-based gaming demo using GameKit because I need this for the game I'm really meant to be working on (yes, I have to get down to some "real" work sometimes). I will hopefully have this ready in the next day or so. There'll be plenty in there to act as a further BhWax tutorial and I'll publish it on my blog.

    I agree that someone could redo the UIKit demo but I haven't got time to do it myself, I'm afraid. Also, I am aware that several people here, most notably Mike Hart and Carnite, have put a lot of work into that plugin (I still don't understand how it all works inside) and I didn't want to suggest, or assume, that BhWax would necessarily usurp it.

    The "iphone-wax-part-2" tutorial is also an interesting candidate and I did consider porting it for a time. I didn't do it for the following reason. It seems to me that there are two distinct uses for Wax. The first is as a generic plug-in replacement for typical Gideros applications. By this I mean, you write a normal Gideros 2D graphics app/game and, when you find a native iOS feature that you need, you implement this with some Wax calls. I'm completely convinced that this is a valid way to go, since I can't really seen any disadvantages to it.

    The other use has also been hinted at; to use this as a means to a rapid application development environment for iOS, where nearly all the coding is done as Cocoa calls from Lua. Now, I think this idea, needs more investigation because there may be speed issues which we haven't seen yet (just calling out to UIKit elements isn't going to cause any speed bumps, whereas writing Cocoa loops in Lua may do).

    Anyway, for those who want to try this latter RAD approach, yes, ignore the AppDelegate.lua stuff and hang off the getRootViewController().

    With regard to errors, what I've seen is that not all of them will actually crash the player. Most of the time I've seen the Gideros app exit back to the player as it does with normal Lua. However, I think there is certainly a problem with crashing if you get any error at all inside a Wax callbac into Gideros. I think it may need somebody with a bit more knowledge of (and access to) the internals of the Gideros player (@atilim?) to be able to trap these successfully.

    best regards
  • BTW, has no one noticed the cocoa_annot.txt file inside the BhWax distribution?

    Best regards
  • atilimatilim +1 -1
    Maintainer
    cocoa_annot.txt whoa! @-)
    (I'll give more information about internals)
  • @atilim, yes I guessed at the api file structure and it so it only does a partial job (it is better than nothing) but it's not quite right. To recreate, load the other project in the BhWax folder.

    Best regards
  • atilimatilim +1 -1
    Maintainer
    I've looked at Autocomplete.lua and it's impressive!

    Once, I wanted to directly bind Objective-C runtime functions https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html to Lua as a plugin. But I haven't got a chance to implement it.

    Anyway, wax is much more easy to use. :)
  • @atilim, if you can provide more details about the .api file and how the autocomplete in the IDE works, I might be able to improve on the cocoa_annot.txt file contents. Alternatively, the method AutocompleteGenerator:formatAutocompleteSelector() can be rewritten any way you like to alter the file contents.

    I'm currently running with the (huge) .api file right now and it works well enough. Because there are so many match possibilities it makes finding shorter sequences a bit harder but it really helps with those long Cocoa names.

    One idea that occurs to me is that, if the IDE were to display the shorter matches first, then one would be able to choose a partial match (by hitting enter), then type some more to narrow down the search even further.

    best regards
  • OZApps said:

    @ar2rsawseen, have you seen this? https://github.com/mkottman/AndroLua
    This is perhaps the Android version of Wax, so all Android users can rejoice and perhaps use this.



    atilim said:

    @OZApps From the description, AndroLua uses LuaJava:
    http://www.keplerproject.org/luajava/
    https://github.com/jasonsantos/luajava

    Also @alexzheng posted this link: http://code.google.com/p/jnlua/

    Both seem good solutions.



    Problem with them seems to be that they are interpreting lua on the Java side, basically allowing to load and run lua file or code in Java, whereas in Gideros we need something that can be called from lua.
    But maybe I'm misinterpreting something, because I didn't have enough time to dive deeply into it.
  • It's amazing for the autocomplete!
    I can not wait to try it, however,I can not see clearly what you did in the video,Is the final xcode project for giderplayer or a simple step to step tutorial to setup the project available?
  • Hi @alexzheng, what is it in the video that you can't understand? I tried to make it quite clear what to do. Have you tried watching it full screen?

    best regards
  • which files have you dragged into the xcode project?

Howdy, Stranger!

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

Login with Facebook Sign In with Google Sign In with OpenID

In this Discussion

Top Posters