What we want to do is develop reliable software that doesn't constantly break. Hopefully we can all agree that is a reasonable goal.
It is, and I don't think anyone would argue against that.
I suspect perhaps some developers got interested in the ability to access internal details, and thought it was cool or useful. However that was only possible due to the historic weakness of JavaScript encapsulation, and if you do that, you will end up with unreliable software that constantly breaks.
I understand your reasoning on that front, but I disagree with calling it exclusively a weakness. On one end yes it makes it very hard to build something completely closed off, but on the other hand, having constant access to the internals (even if all you can do is read them) allows for a lot of good things. Javascript I believe is a beautiful tool for rapid iteration, analysing other people's good ideas and learning how to build on other people's work.
In the case of Addon development, it's kind of a historical way developers around here were raised (including me) by messing around with other people's code and finding ways to iterate on things you were given access to. Of course having access to internal details is cool and useful if only for the fact that it allows us to imagine what things could even exist.
I could point at the long list of features that are now part of Construct that were initially developed by addon developers, often using knowledge of internal details.
I would even go as far as to say that "addons", "mods", "hacks" or any other kind of software that builds on top of other software naturally attracts the kind of developer that would find that useful and cool to know the internals of the thing they're working with. Sometimes it feels like you don't have an understanding of this and then get surprised when you meet developers that actually do this.
If you wish to develop quality software and build addons that are reliable and work in the long term
This is another misconception. Not all software is built exclusively with the intent of it being up to your standard of reliability. For game developers, most of their tools are meant to work for them and nothing more. If it's unreliable but they can deal with it, it's ok. If it breaks in 5 years after the project is long finished, it's also ok.
Now I will absolutely agree that in the case of addons that will be used by other users, there is a need for them to reliable and work without active maintenance.
SDK V2 has value in that it does make things work with less hassle, but that was never the critique of it. The biggest critique was the loss of a lot of things that have just as much worth as stability, like performance, and freedom to mess with things in private (for all the addons that are never shared with anyone else).
Still, yes I try to make all of my addons as reliable as I can make them and I deprecate them when I feel they aren't reliable anymore or when I feel I can keep maintaining them for free.
Also, another perk of Construct in this very specific case is that even if something breaks in a new update, users can always use a previous version as they are all permanently accessible. This is also standard in the industry where addons are designed for specific versions of the engines they are built for, and it is fairly commonly assumed that some addons will break over time and if you want to keep using them you should stick to older versions of the engine.
In the case of an engine such as Unity for example, it's actually even stricter as user made scripts can also break randomly from version to version. This idea that things made on top of an engine should never ever break is very unique to Construct in the game engines industry. Maybe in regular softwares this isn't the case; Perhaps extensions made for Audacity back in 1967 still work with Audacity 3 but that's not something I have seen commonly accepted in other game engines.
Anyway, I understand your point of view, I understand that you are the one in a position of dealing with the pesky users, and I understand why you would do these things. The only thing I ask is to not be thrown under the bus more than once every few years. The move to SDK V2 was a very painful time for me, I basically had to rebuild everything I had from scratch, and I still deal with the consequences of it to this day. I assume it is the same for other addon devs, so reading you wave around threats of an SDK v3 (because this is how it feels for us) is not something we take lightly either.
I am going through the work of porting all of my addons to SDK V2, I have rebuilt my addon framework from scratch, I have submitted countless feature requests, bug reports, and I have spent a lot of time reading the internals of V2 to debug issues I have found for you to make it as easy as possible for you to keep improving V2. I have also opened an open collective to try and help crowdfund development on addons and tools to try and get all of this done a bit faster.
I am not going through all of this again. I am not even saying this to be mean or threatening, but I have a business too. I have done all of this work for free out of passion for the engine you are building, but it has taken a significant toll on me the past few years to do this + manage my own business at the same time, so I am quite definitely never doing this again.
The editor is not designed to have UI extensions.
Sure. When I said "what are you even going to do" I was not talking about the fact that the editor's UI is not exposing an API. I was mostly thinking about the fact that browsers come with their own UI extension API and that it already allows things like events, DOM and Javascript to be completely isolated from one another. What I meant to say is that for as long as Construct runs in a browser I don't think it's ever likely that it will be impossible for Javascript running in the main thread from acting on the DOM.
Anyway, this is not me saying you can't stop what's happening. This is me saying I think it is quite absurd to want to fight the browser so much.
So I have to ask: do you intend to build reliable software that keeps working?
In the case of this editor tools addon, my intent was to experiment with what's even possible. Eventually, yes I would love for it to be reliable and this is why we are talking today. I came up to you saying "here is a solution I am experimenting with, what do you think about it, and what can I improve to make it work better long term?" not "Here is a finished addon that I have shipped to half of the Construct userbase and that I will never work on ever again"
If you do, you won't do this, because you can't guarantee to your users that it will keep working!
If I thought no amount of compromising or talking to you and asking for improvements in the SDK would ever guarantee reliability eventually I wouldnt be doing this indeed.
I've seen some experiments with making a 3D editor that operate on that principle, and it is a good approach.
Not sure which editor you are referring to. Are you talking about this? I don't think I've seen any external editor for Construct that actually provides a fully functional 3D editor.
I have actually experimented with this a lot this year and made this level editor for one of my games:
youtube.com/watch
This could turn into a generic 3D editor tool with some work but for now it's neither here nor there.
I agree that external tools are better when possible but so far Construct still has a lot of limitations. For one, if you want to do anything at all that affects anything in the project that isnt a project file or a script, you have to build something that can read and write project data. I started working on that a while ago with this project:
github.com/skymen/construct-crawler
There is also scope to extend the supported editor APIs to better allow integrating with external tools, such as the existing Custom Importer API
Yes, in fact the whole point of my initial message was: "Please just focus on extending the supported editor API as we try and figure out a proper way to make editors ourselves". If that ends up taking a different form than what I made in my initial experiment, it's fine.
Perhaps one less-bad option would be a supported option to open a popup window which can then show custom HTML and CSS content, and communicates with the editor via postMessage() - at least then the custom stuff is sandboxed within a separate window, it's still relatively flexible, and it's still a long way short of full editor DOM modification.
Yes! I proposed this as a solution as I genuinely can't imagine anything going wrong with this possibility.
Another possibility is having the editor tools run in an Iframe within a built in dialog, like the dialog popup that appears when previewing the game.
In fact, it could use a similar system of choosing between external tab, popup and iframe in a dialog and it would be perfect. From what I can tell, such a system already exists and works perfectly fine for Construct's preview which is also running arbitrary code.
Anyhow, my whole point was not "look I am actively destroying your beautiful editor UI, I am an evil addon developer", but rather "Do not worry about giving access to the UI system, literally give us the simplest possible form of it and we will build our own UI libraries and systems"
I want to finish with an appeal for co-operation. Please consider everything I've written, and do what you can to work with us. If you co-operate and work with us on supported features, such as perhaps a popup window API that is significantly more reliable long-term, perhaps we can end up achieving both some degree of the features you want, while maintaining our goal of making reliable software.
I would love to cooperate, as I always try to make clear. I don't think I've ever gone out of my way to go against your judgment and I have always been transparent about wanting to improve on anything I've made to see how we can make Construct a better engine.
Just let me know how I can better cooperate than what I'm already doing.
My goal (and I assume every other addon dev) is not to create headaches but to create new possibilities.