Part time worker hired to maintain Gideros!

john26

These are great ideas, @Mells, thanks. And BTW, please come back to Gideros!

One way to find out what new features have been added to Gideros is to look at the release notes for new versions of Gideros:

http://giderosmobile.com/download

But we also need to get serious about the blog posts and ensure at least one blog post is written each month. I think that would be a good way for new users or "silent" visitors to get a quick view of recent changes. Of course the blog has been around for years but we need to post much more frequently, at LEAST once per month and hopefully a lot more than that.

Also, we will prepare press releases for each Gideros release from now on.

keszegh

yes, blog posts about new fetures, etc. are important. i also check these for other frameworks i don't use but i'm interested in how they improve over time.
also e.g. i still get the corona emails which emphasize some 'great' new feature or new app made with the framework etc. even though i lost interest in using their sdk years ago, it's just convenient to be updated about where are they now. the same for gideros would be great so that this way people know about the progress without direct effort, once they subscribed.

logidzk

Yes, there are several Lua libraries which are vital to many/most projects but which are not officially part of Gideros so are not documented or centrally located. GTween is a good example of this, it's not officially part of the Gideros SDK yet is so important to developers that it has become de facto part of the standard. It is included in the Gideros examples, which is good, but is not officially documented. The closest thing I saw to specification of the GTween parameters is here:

http://appcodingeasy.com/Gideros-Mobile/Gideros-GTween-with-easing

This should certainly be included in the main Gideros SDK documentation I think, maybe under its own section called "Lua libraries" to go alongside the Plugins section of the SDK docs:

http://docs.giderosmobile.com/reference/plugin

I'm also thinking we could merge the "labs" section into the "plugins" section since many people will not know the significance of the word "labs". Finally plugins which are exported by default should be migrated to the "Main API" section IMO.

Hi john26. Not sure if we can bundle the lua files as part of Gideros framework? For example, users can just call dataSaver function in the editor without adding the lua file manually.

Users can also contribute to these lua files by extending the Gideros api such as menubutton.lua, scrollview.lua, animation.lua, jump.lua, rateme.lua which can be instantiate easily for any project.

If we can do that, I am sure we can put in a lot of useful lua function and improve the capabilities of Gideros overall

ar2rsawseen

@logidzk how do you imagine that overally?
On one hand you want everything to go into Gideros without adding specific files to project
but on the other hand you want it to be all expandable and extendable.
How would that work?

talis

@logidzk I can only imagine it one way which i don't like it so much by myself hence it will be client depended and no control. I by myself hate automated process.

In the Gideros IDE there will be special classes and keywords for those classes.
Whenever you will use the word #include Textwrapper or #include any_valid_class_name IDE will automatically add the required lua code.
But as i said in my opinion anyone who is contributing to gideros should have to spend his/her time for any other functionality rather than this one or bug correction.
In my opinion this has the lowest priority of the needs and even the necessity should be discussed

In other hand i will be so much happy if those code fragments or classes will be collected in somewhere and updated one by one for everyone's usage.
I know in Gideros website they are all there but lot's of them can be outdated already.

Maybe we can create a small project team of volunteers who would like to deal with this issue. We can contact the people who developed those classes one by one or we can alter the code by ourselves to make them up to date again, or test them.

antix

I think that some classes (like the button class, textWrap class, etc) could just be packaged with the main distribution, with some documentation provided in the main reference library.

I don't think there is really an option to have things magically included for you without a lot of work which would be better spent on more useful things (improvements).

I think just making sure the classes are included in the main distribution and documented in the reference guide would suffice.

SinisterSoft

Maybe a something in the project properties that you can tick/untick with a list of the 'built-in' include files could work? These could then be added to the project automatically in the background (so you don't see them in the list of files on the left) when it's sent to the device or exported.

ar2rsawseen

How about having a package manager?

A command line and an online registry of github repos.

so you can do something like

gideros install TextWrap

and it would download text from to current directory and add it to the project's libs folder.

antix

Please.. for the love of humanity.. no command line stuff =P~

hgy29

Maybe the best way would be to have those lua files packaged with gideros distribution, so that user just need to reference them in their project from gideros installation directory. Those files would be hosted on github along gideros so that people can contribute to them. What do you think ?

antix

@hgy29, that was my thinking. It would probably take the least amount of effort too. Just as long as there is documentation for the different classes in the reference guide it would be fine.

john26

Hmm, personally I think it's ok for users to simply copy the LUA file into their project directory then link to the project within Gideros Studio. The advantage of that is you can see at a glance what Lua libs you are using. Also Lua files are quite easy to deal with as they are human readable and the Gideros user is already familiar with Lua and the Gideros Studio IDE. And Lua files are not OS-specific so the user doesn't need specialist knowledge of particular operating systems

What I think does need to be automated is the plugins, and we are in the process of doing that. Plugins contains binary files and are OS specific. Adding plugins to a project means the user needs to be happy to tinker with OS-specific IDE's like Xcode, Visual Studio etc. We should not assume the Gideros user knows about these systems, that detracts from the OS-agnostic nature of Gideros. So automatic plugin export is vital IMO -- and will soon happen.

But we should archive and document the "official" Lua libraries on an easy-to-find place on the website.

keszegh

"But we should archive and document the "official" Lua libraries on an easy-to-find place on the website. "
would be perfect.

ar2rsawseen

Command line was just a default usage interface, obviously it would be IDE integrated, like Nuggets for VS.
But, yeah, it would take too much effort

Tom2012

This is fantastic news. Can't wait for the updates!

Good luck and all the best

john26

Just to keep you all informed, With the help of Arturs and others, I'm now making steady progress understanding the parts of Gideros I haven't previously dealt with. I can now compile the Android libraries, players and plugins myself and have also automated the build process for Win32 and WinRT. I've also learned (to an extend) how to alter the website and have made some changes to the online documentation

http://docs.giderosmobile.com/deployment.html

which is now much more detailed, but more to come!

So I'm now at the point where I can build all the targets that can be built on a PC (PC, Android, Win32, WinRT). The next step will be to go get the Mac side of things up and running (OS X, iOS).

I've also made some contributions to the next release which should be out this week!

keszegh

good news.

there is an issue with wacom tablet events registered many times which @hgy29 tried to sort out (with help from @tkhnoman and complaining and testing by me), please do something with it before this release.

antix

@john26, Awesome! You have put a lot of work into this and I'm impressed. I really look forward to direct APK exporting

talis

@john26 great to hear about the processes are going smoothly. Looking forward to see the new version, really appreciated the job done.

hotbuttered

This is great news! @john26 I hope you won't be shy about prominently displaying links to the preferred method(s) of donation. For example there could be a donation button on the home page and here on the forum. I would hate to think people might glance at the title of this thread and presume that there's a source of funding other than donations.

hotbuttered

Regarding the helper lua files that are currently not part of the gideros distribution, perhaps something like the postgres contrib module convention could be followed - the contributed modules are distributed as part of postgres packages, but they need to be individually installed in order to use them.

For example, the extra lua files could be distributed under a directory named contrib/ (or similar) along with specific documentation and a general note on how to add them to a project in gideros studio.

john26

Hi, @hotbuttered and welcome to the forum! Yes, I am going to put up donation buttons in various places soon and hopefully in time for the next release.

icworx

By watching the Gideros repository it seems things are coming along well and active , but definitely need some more time to polish the things to be ready for release.

While 2016.4 is taking shape in GitHub, the major hassle is to compile and make releases(which is always a pain for multi-platform engines).

antix

@icworx - Gideros does need some tidying up but people are creating and releasing products with it. It just needs polishing for noobs (like me) I suppose =:)

It will be really awesome when Gideros can just create APK files from inside Gideros Studio.

simwhi

We are waiting eagerly in anticipation for the new release!!!

talis

New release and donation button =D>

SinisterSoft

imho One of the best upcoming features is multiple viewports, I updated Dungeons today with the new Viewport sprite type for split screen multiplayer...

MikeHart

@SinisterSoft: That is nice looking project you have going there.

antix

Multiple View ports could be used in some interesting puzzle games

SinisterSoft

@MikeHart Thanks.

Here it is on an old Kindle Fire - testing split screen - no slowdown at 60hz.

(the split screen line disabled until I figure a nice way of doing it, but it is split left/right)