@sslivka, yes, when you select Gideros as the interpreter in ZBS ("Project | Lua Interpreter | Gideros"), you should get autocomplete for Gideros API calls.
For example, typing "application." will give you a list of methods for the "application" object and if you then select one and type "(" you get a tooltip with method descriptions. Is it not working for you? What version of ZBS are you using?
@paulclinger, I using ZBS version 0.37, and it has autocomplete for Gideros API, but it does not support auto-completion for the methods of the parent classes, for example if I write: local bm = Bitmap.new() bm: I do not get the Sprite class methods, but Bitmap class inherits Sprite class. And how to make auto-completion of variable names? Can you add stage global variables, an object of class Sprite? Thank You.
I do get 5 methods in auto-complete list (including setAnchorPoint and getAnchorPoint). The current implementation doesn't support inheritance between classes in the API; this has already been requested and may be included in the next version.
I did find a couple of issues with Gideros API; the auto-complete was not suggested until you type at least one "." or ":". I already fixed that and also updated the API description with the latest version available from the link that @ar2rsawseen referenced. It should be checked in later today.
> And how to make auto-completion of variable names?
Do you mean auto-complete for variable names you used elsewhere in your scripts (for example, you already typed "abcdef" and want it to be suggested after you type "ab") or do you mean auto-complete after "bm:" as in your example?
The former is enabled using "dynamic words" and the latter should already work.
> Can you add stage global variables, an object of class Sprite?
What do you mean by "stage global variables"?
As I said, inheritance is not supported, but what you can do though is to modify api/lua/gideros file to copy methods from Sprite class to Bitmap class before returning the auto-complete data.
Is there any information on what classes inherit what other classes in Gideros?
@sslivka because Gyroscope does not have new method it can't create new instances, it has only one instance gyroscope, same for Application and lots of plugin classes. At least I thought it was this way, let me check.
@paulclinger would it help if this automatically generated autocomplete.php would also list inherited methods?
@sslivka, thanks for the ref to the inheritance information.
@ar2rsawseen, thank you for the prompt update; no, I wouldn't want the methods to be copied from the inherited class and would prefer to mark the class as "inherited" in my API descriptions.
BTW, I have been processing the new description with my script and noticed several other issues with descriptions that didn't exist in the previous version of the documentation I have. I'm attaching the diff file; in most cases the old description (marked with -) is the correct one with two exceptions: "sprite's coordinates" has incorrect Unicode character (can you change it to '?) and "force" is used in stead of "torque" (I marked those instances). Can you fix these issues? Thank you.
It would be useful to include inheritance information in a text form in your autocomplete file:
Bitmap > Sprite TexturePack > TextureBase and so on.
It would also be useful to have a list of global variables that are present in the environment (like "application", "stage", "world" and so on) as I could also add them to the auto-complete list). Are there any in addition to these three? What are the methods of the "stage" variable?
In my "gideros.lua" I just copy and paste the common methods of Bitmap and Sprite, and methods for the point (Bitmap.new (texture)) determined the type "type =" function "", and for methods with a colon (Bitmap: setAnchorPoint (x, y) ) - "type =" method "".
@sslivka, good point, I should eliminate the duplicates.
I didn't quite get your comment about "method". Do you mean that all the function (except "new") should really have "method" type? I think it's a good idea, I can update that...
@paulclinger >I didn't quite get your comment about "method". Do you mean that all the function (except "new") should really have "method" type? I think it's a good idea, I can update that...
No, I think you not understand me. I mean that in Gideros API there are class methods that are called by a dot (.) and colon (:), for example:
@sslivka, yes, this is how I understood it, so we are on the same page .
The challenge is to figure out which functions are "functions" and which are "methods". It seems like "new" and "is*" should be "functions" and the rest are "methods", right?
Right, got it. So, looking at the auto-complete description for Event:
Event.new(type) Event - creates a new Event object getTarget() Event - returns the element on which the event listener was registered getType() Event - returns the type of Event stopPropagation() Event - stops the propagation of the current event in the scene tree hierarchy
The first one would be "function", but the rest would be registered as "method" (so they are offered after "event:" is typed).
@ar2rsawseen, in general, everything that has Class.function is a "function", but functions that don't include class name are "methods", correct? I'm ignoring "values" for now as those are already handled...
@paulclinger if you are talking about autocomplete.php then yes, all class functions are passed as ClassName.function() while methods are passed as method() ClassName
@sslivka, both of the issues should be fixed: removed duplicates and separated functions from methods. Let me know if you notice anything else that may be wrong.
@ar2rsawseen, the way it is now in the docs is fine; it was a short update to the script to separate functions from methods.
@sslivka, let me know if you had a chance to try the latest version that removed the duplicates and added proper handling of methods. I'm packaging a new release and want to make sure Gideros auto-complete API is working as expected. Thanks!
@paulclinger - if you're creating a new release, might I humbly suggest that the Mac release gets a more thorough check? Last time I looked it had a bunch of references to C:\Program Files and various samples were broken. I still can't work out how to do remote debugging on a device - I'm not interested in using ZBS for the Gideros local player as my builds rely heavily on Obj-C plugins that only function on a device or the Xcode simulator, hence triggering the Gideros Player for debugging is not useful.
I would like to offer some time to help you track down the Mac package issues if you don't have handy access to a Mac, but I would *love* to get the remote debugging working on a device.
Comments
http://docs.giderosmobile.com/reference/autocomplete.php
Likes: sslivka
For example, typing "application." will give you a list of methods for the "application" object and if you then select one and type "(" you get a tooltip with method descriptions. Is it not working for you? What version of ZBS are you using?
local bm = Bitmap.new()
bm:
I do not get the Sprite class methods, but Bitmap class inherits Sprite class.
And how to make auto-completion of variable names?
Can you add stage global variables, an object of class Sprite?
Thank You.
local bm = Bitmap.new()
bm:
I do get 5 methods in auto-complete list (including setAnchorPoint and getAnchorPoint). The current implementation doesn't support inheritance between classes in the API; this has already been requested and may be included in the next version.
I did find a couple of issues with Gideros API; the auto-complete was not suggested until you type at least one "." or ":". I already fixed that and also updated the API description with the latest version available from the link that @ar2rsawseen referenced. It should be checked in later today.
> And how to make auto-completion of variable names?
Do you mean auto-complete for variable names you used elsewhere in your scripts (for example, you already typed "abcdef" and want it to be suggested after you type "ab") or do you mean auto-complete after "bm:" as in your example?
The former is enabled using "dynamic words" and the latter should already work.
> Can you add stage global variables, an object of class Sprite?
What do you mean by "stage global variables"?
As I said, inheritance is not supported, but what you can do though is to modify api/lua/gideros file to copy methods from Sprite class to Bitmap class before returning the auto-complete data.
Is there any information on what classes inherit what other classes in Gideros?
- What do you mean by "stage global variables"?
sorry, I mean global variable "stage" which is object of Sprite class.
In @ar2rsawseen link (http://docs.giderosmobile.com/reference/autocomplete.php) it does not describe the class inheritance. This can be seen here http://giderosmobile.com/docs/refmanual/reference_manual.html
For example Bitmap class inherits from Sprite class:
that's all there is:
Gyroscope
Gyroscope.isAvailable()
getRotationRate()
start()
stop()
At least I thought it was this way, let me check.
@paulclinger would it help if this automatically generated autocomplete.php would also list inherited methods?
http://giderosmobile.com/docs/refmanual/reference_manual.html#Gyroscope
say:
local gyroscope = Gyroscope.new()
gyroscope:start()
thank you
@ar2rsawseen, thank you for the prompt update; no, I wouldn't want the methods to be copied from the inherited class and would prefer to mark the class as "inherited" in my API descriptions.
BTW, I have been processing the new description with my script and noticed several other issues with descriptions that didn't exist in the previous version of the documentation I have. I'm attaching the diff file; in most cases the old description (marked with -) is the correct one with two exceptions: "sprite's coordinates" has incorrect Unicode character (can you change it to '?) and "force" is used in stead of "torque" (I marked those instances). Can you fix these issues? Thank you.
BTW, I can also try to provide rest API for Gideros docs, about objects, methods and inheritance, etc, just let me know what you need
In terms of rest API: do you mean providing a way to query additional information using URLs like "http://giderosmobile.com/API/Accelerometer/getAcceleration"? It may be interesting, but I think it's an overkill for now
It would be useful to include inheritance information in a text form in your autocomplete file:
Bitmap > Sprite
TexturePack > TextureBase
and so on.
It would also be useful to have a list of global variables that are present in the environment (like "application", "stage", "world" and so on) as I could also add them to the auto-complete list). Are there any in addition to these three? What are the methods of the "stage" variable?
Also, does StoreKit have "new" method as well?
And I've also added inheritance as you've specified
But all of that is in automated manner, so there may still be some errors
@paulclinger, @ar2rsawseen, thank you guys!
Thanks @ar2rsawseen; I'll take a look at handling inheritance in the auto-complete logic...
> bm:
> I do not get the Sprite class methods, but Bitmap class inherits Sprite class.
@sslivka, @ar2rsawseen, I pushed the changes that implement inheritance in auto-complete (https://github.com/pkulchenko/ZeroBraneStudio), so the fragment above should work now. Give it a try.
not good.
In my "gideros.lua" I just copy and paste the common methods of Bitmap and Sprite,
and methods for the point (Bitmap.new (texture)) determined the type "type =" function "", and for methods with a colon (Bitmap: setAnchorPoint (x, y) ) - "type =" method "".
But it is still better than it was before
I didn't quite get your comment about "method". Do you mean that all the function (except "new") should really have "method" type? I think it's a good idea, I can update that...
>I didn't quite get your comment about "method". Do you mean that all the function (except "new") should really have "method" type? I think it's a good idea, I can update that...
No, I think you not understand me. I mean that in Gideros API there are class methods that are called by a dot (.) and colon (:), for example:
The challenge is to figure out which functions are "functions" and which are "methods". It seems like "new" and "is*" should be "functions" and the rest are "methods", right?
Event.new(type) Event - creates a new Event object
getTarget() Event - returns the element on which the event listener was registered
getType() Event - returns the type of Event
stopPropagation() Event - stops the propagation of the current event in the scene tree hierarchy
The first one would be "function", but the rest would be registered as "method" (so they are offered after "event:" is typed).
@ar2rsawseen, in general, everything that has Class.function is a "function", but functions that don't include class name are "methods", correct? I'm ignoring "values" for now as those are already handled...
But you may suggest other way to separate them
@ar2rsawseen, the way it is now in the docs is fine; it was a short update to the script to separate functions from methods.
I would like to offer some time to help you track down the Mac package issues if you don't have handy access to a Mac, but I would *love* to get the remote debugging working on a device.
Many thanks.
Best,
- Ian