Scripting In Atlas

[Ykkrosh]

Some random points about the current situation:

* Atlas supports some parts of the UI being written in JS instead of C++, in particular the panels on the left and bottom of the main window (and not any other parts of the UI like the menus or the toolbar).

* I think UI scripting is nice primarily because you can tweak the layout coe and see the change instantaneously, instead of waiting 30 seconds to recompile and restart.

* There's some bugs caused by (lack of) interactions between JS and C++, e.g. toolbar and panels not staying in sync when selecting tools.

* Atlas relies on wxJavaScript to let JS create and manipulate GUI widgets.

* We use an old version of wxJS which has some minor missing features (e.g. tooltips), major missing features (e.g. wxAUI which does dockable windows and toolbars and stuff, wxPropertyGrid), and various minor bugs. When writing new JS code it's fairly often necessary to fix some of the minor problems in wxJS's C++ to get it to work alright, which destroys some of the benefit of writing in JS.

* New versions of wxJS seem to have pretty much the same problems, with little active development, and also have a dependency on another large library (POCO).

* I'd be surprised if wxJS didn't have some compatibility problems with future versions of wxWidgets (2.9+, which is released but not common yet); it already triggers some deprecation warnings.

* There's some odd bug when using wxJS with a recent version of SpiderMonkey - all the GUI widgets get stuck in the top left corner of their panel and the automatic layout doesn't occur. I spent a few hours trying to debug it and totally failed. (That's the main reason I'm worrying about this now.)

* The Atlas UI currently seems to be about 17K lines of C++, 1.5K lines of JS.

* Some of the JS was originally ported from the C++, so the C++ still exists in the history somewhere.

I think fixing Atlas's UI scripting system to work decently would be a large amount of work: fixing the SM upgrade bug (I have no idea how long that would take - probably it's something trivial but I don't know where to look), improving the interaction between C++ and JS, and continually adding features and fixes to wxJS as they're needed.

I think porting the scripts back into C++, and then deleting the scripting system, would likely be less work in the long term: there's not that much JS code, and it'd be a bit tedious but straightforward. (I'd be willing to do that work myself). The only real loss would be the speed of reloading changes, which can be alleviated by buying faster computers. The only user-visible changes should be minor improvements.

(I think porting Atlas from wxWidgets to Qt and using QtScript for scripting might give a better end result but would take far too much work to be worth it, so that's not a serious option.)

Thoughts?

[historic_bruno]

Well you and I discussed this already, of course.

Scripting makes much more sense in the game than it does in the scenario editor. The ability to instantly prototype is nice but not used often. Any really useful changes to Atlas require knowledge of C++ anyway.

So in my opinion it's not worth having to maintain wxJS and be tied to an old version of wxWidgets, just to support functionality that isn't used.

[Ykkrosh]

Well you and I discussed this already, of course.

Yeah, sometimes I change my mind when trying to write down summaries, but I haven't yet, and nobody else has expressed disagreement, so I've started working on porting stuff back to C++ now.

[Ykkrosh]

Done - the 4-year experiment into UI scripting is now officially a total failure.

The only intentionally removed functionality is the 'new map' dialog box - the implementation via RMS seemed to complexify the map settings data (I think it was some combination of player_defaults.json, settings from the last loaded map or RMS script, the current map settings UI, some values from the C++, and some values from the dialog), and it was inconsistent with the new map you get when first launching Atlas, so now it just does the same as first launch (i.e. load the "_default" map) which seems to make everything much simpler and more controllable. To replace the dialog's functionality, I added a "replace terrain" tool, which is like the normal "paint terrain" except it paints every tile that's using the same texture as the one you click on, so on a blank map you can easily replace the default grass with any new texture (plus you can use it non-blank maps if it happens to be useful). Also I added a "resize map" button, which is pretty limited and unreliable but works for blank maps. There's no way to change the default height trivially (though you can raise/lower then use "flatten" with a giant brush size) - it'd be good to add a feature that can raise or lower the entire map at once (and tell you whether it's clipping at either end).

Otherwise I think it should be pretty much the same as before. Hopefully I didn't add too many more bugs - please complain if there are any (other than general ugliness).

[janwas]

Since you and I are also active in the research field (once cleverly defined as "that which I am doing when I don't know what I am doing"), we get to declare certain things to have been `instructive' rather than just a failure, providing we did actually learn something from it

Sorry to hear it was a dead-end, but I'm glad you're rolling it back rather than letting it fester.