> On 28 May 2018, at 2:40 am, Pi Digital via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Thanks for the clarification, Monte. > > But just to clarify in return (respectfully), when I spoke of IDE changes I > was specifically referring to the Project Browser (omitted from your quote). > As the greatest extent of items within the IDE that need fixing are GUI with > the majority of their code within their respective stacks. I’d started on the > project browser back n it’s early days but quickly got shut down by two of > LCs former coders. I even created a stack comparator but they weren’t > interested (surprisingly).
OK well this may or may not have been before my time with the company so I’m not sure what as involved. If you find your patch needs to touch scripts in binary stacks then I would recommend the following: - ensure there is a bug/enhancement report for what you want to do - open up a report requesting the scripts you want to edit be turned into script only stacks and mention you will fix the original report if this is done. This will need to be done by someone on the team but as it doesn’t take long, we want to do it anyway and we like to help out people that are contributing we should be able to do it fairly quickly. - wait for the scriptification then make your patch to that. If your patch involves changes to the controls on binary stacks then the best we can offer at the moment is asking you to write a script that makes the changes. That will actually help us if we have a merge conflict and is a process we have used once or twice even within the team. For example when legacy inks were removed I wrote a script to fix them and we applied it to multiple branches die to a merge conflict. The best thing you can do is communicate with the team what you would like to work on and we will help in whatever way we can. Gitter is a good venue for such discussions. > > I appreciate, though, that google had been a bit rubbish at notifying, mainly > because they relied mostly on notifying when people logged in but our API had > silent mode on so we never heard. In my defence however, oAuth and similar > have been under review by every provider for the last three years due to > security, so perhaps having looked during those years for anything that uses > oAuth or similar to ensure they are up to date. Now is probably a good > opportunity to check all of the other ones. Yes I have opened a report to update the oauth2 library as soon as we can. > > I hope this doesn’t touch a nerve, but why hasn’t the mergext stuff been set > as open source also. This would be useful to the community with regards > building extensions for LiveCode (similar to the new sockets library). There are some mergExt externals that were always open source and still are. The rest of it fit into Indy and Business to add product differentiation. > >> All we need is a decent bug report for anything that isn’t open source > > And then we just need to wait several months potentially before that fix sees > the light of day. Not helpful! Not necessarily true either. There are a number of factors that are involved in determining what makes it into our fortnightly sprint. Ali is probably the one to discuss that though. Cheers Monte _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
