Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
Comments
@keszegh, the dropdown in the toolbar is not enough?
> otherwise keep up the good for, zbs is my favorite ide.
Good to hear! I just recently released v0.70. Will do a separate post on it.
@paulclinger,
a dropdown needs one more click and also one cannot see an overview, so an outline would be much better so that i always see the structure of the file. like in flashdevelop the 'outline' window, although in lua probably it's harder or impossible to list the variables too (although it would be great to list for each file the classes in it, for each class the functions and for each function the local variables defined there. and also the 'self.something' type variables where self is the current class).
in any case just always having a window with the content of the current function list dropdown would be already quite good.
another thing which might be hard to do but would be useful is autocompletion for classes and functions that we defined. i think on the forum somebody make kind of a script that parses the lua files and generates an autocomplete file from it, so something like this done automatically in zbs would be great.
so these are my suggestions, but as i said i'm already quite happy with zbs (and the new ctrl-i auto-indentation is a blessing for me as i always mess up my code).
Fragmenter - animated loop machine and IKONOMIKON - the memory game
@keszegh, thank you for the suggestions. Yes, I've been trying various approaches to see what may work as a replacement for that dropdown. What you are recommending may work, but it has some disadvantages as well. I'm curious, why are you interested in local variables? One problem with displaying local variables is that they may be defined in sub-chunks of a function; how would you display it then?
Actually, what *may* work as an outline is a way to collapse all lines in a file that don't start a new block and don't start with "local". This gives you immediate overview of the file that you can still navigate. I'll need to try that, but it may work quite well (although it will need to be turned on/off as it will be hiding some of the lines).
> another thing which might be hard to do but would be useful is autocompletion for classes and functions that we defined. i think on the forum somebody make kind of a script that parses the lua files and generates an autocomplete file from it, so something like this done automatically in zbs would be great.
Functions are a bit easier; classes are more problematic. I can assure you that I'm researching a ways to support this as it could support various related functions (like auto-complete, code navigation, re-formatting, refactoring and so on), so I'm interesting in finding a good, fast, and reliable way to do this. I've been looking at typedLua and metalua to support this, but it's still very much in the prototype stage.
Paul.
i also doubt that locals i would be interested in much. on the other hand 'globals of a class', i.e. the variables that i define inside functions as self.var1 self.var2 etc. would be useful to see all the time.
about the class and function structure/list an all-time visible list (in a window) would suit me better than your idea of one-click all-collapse, as by collapsing i just loose my place in the code and then i have to readjust when opening back. so my preference is something that is visually just like the file-list window now, contentwise it can be exactly the same as the function dropdown [and then a list of classes and self.var-s would be a plus, but less crucial].
but it's up to you, of course, perhaps you may ask other users what they think/prefer to see if i'm alone.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
also i tried again the live coding stuff in it and it is quite simple and useful, wish i've started to use it much earlier. bowerandy's tutorial is great but i think there could be an updated and much simpler, more to-the-point tutorial as in fact a few lines can make it work for e.g. testing menu element positions you just make a global temporary function containing the positioning and you add an eventlistener calling it at enterframe. when you are happy with the position, you just delete the whole stuff.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
say you want to position/fine-tune something in some function Fun in some class Cla
then
inside Cla:Fun()
add
stage:addEventListener(Event.ENTER_FRAME, function(s) pcall(liveupdate, s) end, self)
and in the root of the file (e.g. Cla.lua) add the function with the functions you want to fine-tune, e.g.:
function liveupdate(self)
self:setPosition(183,505)
self.subObject:setPosition(100,100)
self.subObject2:setScale(2)
end
now start a livecoding session and you can fine-tune the properties by changing the values, you can add new lines during this session to the function etc.
when you are done, you paste back the content of liveupdate to the right place in Cla:Fun (in place of line where you added the eventlistener) and remove the line that adds the eventlistener.
then you can use the same liveupdate function in a similar way to fine-tune some other properties in some other class. etc. you can do lot of other things.
there are some limitations in what you can liveupdate, e.g. if the function is a local inside Cla:Fun() then it does not live update for me, but e.g. it could be a function of Cla, e.g. Cla:liveupdate(self) and it would still work. in any case this is enough so that one can play around with livecoding. i'm far from understanding it's quirks.
also in an arbitrary function of some class if i change something during the live session and then the function is called again later, it did not update for me, so one really needs an onenterframe event for this stuff. i don't know why this is needed, as theoretically i don't see why it would not work. but anyway, it's already a strong tool.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
thanks
Fragmenter - animated loop machine and IKONOMIKON - the memory game
and best would be to be able to check somehow if a player is running and in that case the program is loaded into that, otherwise a player is started and loaded into that.
and of course when pressing stop the player should rather not close.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
I agree, it would be useful (or even necessary to restart the script), but I'm not sure it's possible to detect that in a general way... I'll check.
Likes: keszegh
also, with v1.1 of zbs the project is not starting in the player. when i push the play button then a gideros desktop player starts and there is some feedback in the console, so connection is there, but the project does not start, so approximately 'gdrbridge play *.proj' is not happening.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
"Debugger server started at lt7:8172.
Program starting as '"C:\Program Files (x86)\Gideros\GiderosPlayer.exe"'.
Program 'GiderosPlayer.exe' started in '...' (pid: 7840).
Starting the player and waiting for the bridge to connect at 'C:\Program Files (x86)\Gideros\Tools\gdrbridge.exe'.
Starting project file '...\.tmp\'.
GL_VERSION:3.3.11672 Compatibility Profile Context
GLSL_VERSION:3.30
Loaded shader:1
Loaded shader:2
VIndices: 0,2,1,3
FIndices: 1,2,0,4
GL Program log:Validation successful."
(i changed the path to my project to ...)
then nothing happens.
btw if in the now open player i manually start a project (file/open project) then it is debugged in zbs, e.g. the print command is sent back to the zbs console.
that's why i think that the only thing not working is sending the project to the running gideros player.
also i note that i changed some timeout values in gideros.lua as otherwise zbs does not wait enough for the player to start.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
"Starting project file '...\.tmp\'."
while the previous zbs outputs:
"Starting project file '...\myproject.gproj'."
Fragmenter - animated loop machine and IKONOMIKON - the memory game
i had to change some timeouts (i changed a 15 to 115 and a 30 to 130 in gideros.lua), it would be good to know more about which number to change to what in gideros.lua to achieve a sensible balance so that the values are not too big but it waits until the player starts, so far i just make random adjustments until it works.
in any case if you manage to detect if a player is running then probably you can do somehow that the player runs constantly and one can run/stop projects in it without stopping the player. that would be optimal.
thanks for all, zbs is great.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
since a while (i really don't remember since when, but not always, i think) in zbs many errors are not handled.
if there is a typo then it warns me in the output window. however, e.g. when i call a function like somefn:start() and somefn does not exists (it is nil), then there is no error message (in gideros studio there would be) just my app does not start in the player without warnings. another example if i accidentally try to make a texture from a non-existing file (mistype the file name) then there is again no error message and the app does not start.
because of these i have to regularly run gideros studio when such an error with no message happens to find out what's happening, which makes debugging much more complicated.
thanks for trying to handle this.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://deluxepixel.com
http://metalua.luaforge.net/src/lib/strict.lua.html
@keszegh, I would be interested to see how gideros studio does it as I can only show what's being sent by the process the IDE launches to the standard output/error stream (in this case it's "gdrbridge play" command).
https://github.com/gideros/gideros
or more specifically this may be a place to look for (i guess only):
https://github.com/gideros/gideros/tree/master/ui
but maybe @ar2rsawseen or other core members can help out too.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
so it seems that the error messages (evoked by strict.lua in this case) are not received by zbs. if this is due to gdrbridge, then some core developer should help out @paulclinger how to receive error messages.
Likes: totebo
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Unfortunately I have couple of large features in to do list before that would be accomplished
BTW is Gideros support implemented in the core of zerobrane, or there is somekind of plugin mechanism? Cause if it would be plugin, it could be easier, cause that would allow to manage it on both sides, Paul's and Gideros community
https://github.com/pkulchenko/ZeroBraneStudio/blob/master/interpreters/gideros.lua
as far as i remember in the past (say 1 year ago) error messages were handled by zbs correctly, so perhaps something can be done to make it work again even before complete separation of communication with player.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
@keszegh, it's possible that it worked in the past because ZBS debugger is using debug.traceback assignment trick that only works with Lua 5.1. If/when gideros switched to LuaJIT, it stopped working.
> BTW is Gideros support implemented in the core of zerobrane, or there is somekind of plugin mechanism? Cause if it would be plugin, it could be easier, cause that would allow to manage it on both sides, Paul's and Gideros community
Yes, as @keszegh said, it's a separate interpreter module and I've been thinking about making it a standalone plugin, which would allow some additional functionality, like a filetree menu with project management functions. It would also be in the separate package repository and you (or anyone else) could submit changes to it.
> I think nothing much will be possible till we separate communication with player into separate command line tool. Like we did with export recently, which is now completely controlled from command line.
@ar2rsawseen, if this somehow works for Gideros Studio, maybe the same mechanism can be used in ZBS as well? How does run-time error get reported back to the IDE in your case?
First step would be to determine what have changed.
Does new zerobrane work ok with old Gideros, or new Gideros with old zerobrane?
That way we would know on which end lies the problem