@vladislavbelov should this code not be in other source/gui/ code where all the other GUI code is, for two reasons (1) cohesion and (2) performance (onTick)?
About (1), I suspect C++ has access to things that JS doesn't have access, but would either required or useful to be accessible / interactable / configurable in this context.
But I can't make a conclusion without having seen the thing in action.

This does sound like a 'core' c++ feature to me, but having a JS implementation first and then possibly porting it to C++ sounds like an interesting approach to me.

However I agree that the two resizeBars are a bit confusing and I'd put a full "example usage" on top of the component.

In D1825#75596, @wraitii wrote:

However I agree that the two resizeBars are a bit confusing and I'd put a full "example usage" on top of the component.

I thought it was pretty standard having the class definition uppercased and the instance of such class lowercased.

As for the example, will add it shortly.

This does sound like a 'core' c++ feature to me, but having a JS implementation first and then possibly porting it to C++ sounds like an interesting approach to me.

Is C++ the correct place to implement the feature idea or not?

In D1825#77536, @elexis wrote:

This does sound like a 'core' c++ feature to me, but having a JS implementation first and then possibly porting it to C++ sounds like an interesting approach to me.

Is C++ the correct place to implement the feature idea or not?

Because if C++ is the right place to have it, then committing it in JS means that writing it in C++ is deincentivized as compared to not committing it in JS.

On the other hand we have JS because it makes coding much easier and quicker.
So if there is no performance issue of onTick and determined not to be a wrong layer of of abstraction, then JS would be ideal and porting to C++ later would be wrong.

If JS was the better choice, then one may consider allowing the developers to specify JS GUI object types in JS instead of C++, somehow (JSInterface_IGUIObject.cpp). Such a formalization might or might not have some advantages.

(Perhaps some part of it would be better in C++ and some other part in JS, hypothetically...)

Because if C++ is the right place to have it, then committing it in JS means that writing it in C++ is deincentivized as compared to not committing it in JS.

I don't necessarily agree (see perf below). Furthermore, overall workforce is limited. If we have this in JS and it's not ideal but it works well enough, people who would have written c++ will do something else, and overall we'll have more features. That could be better.

On the other hand we have JS because it makes coding much easier and quicker.
So if there is no performance issue of onTick and determined not to be a wrong layer of of abstraction, then JS would be ideal and porting to C++ later would be wrong.

Performance issues depend on usage. What is quick enough now may become too slow in the future.

Regardless of the above, I wonder if this is the first such feature for which we are popping an object at runtime from the global nether. That seems like a different direction from our current GUI items.

In D1825#77538, @elexis wrote:

In D1825#77536, @elexis wrote:

This does sound like a 'core' c++ feature to me, but having a JS implementation first and then possibly porting it to C++ sounds like an interesting approach to me.

Is C++ the correct place to implement the feature idea or not?

Because if C++ is the right place to have it, then committing it in JS means that writing it in C++ is deincentivized as compared to not committing it in JS.
On the other hand we have JS because it makes coding much easier and quicker.
So if there is no performance issue of onTick and determined not to be a wrong layer of of abstraction, then JS would be ideal and porting to C++ later would be wrong.
If JS was the better choice, then one may consider allowing the developers to specify JS GUI object types in JS instead of C++, somehow (JSInterface_IGUIObject.cpp). Such a formalization might or might not have some advantages.
(Perhaps some part of it would be better in C++ and some other part in JS, hypothetically...)

If you want a reason as to why I've written it in Javascirpt:

• It was originally written for my mod, so asking people to compile 0ad just for this wasn't an option.
• For all intended purposes works just as fine as a C++ implementation.
• Is faster to change if needed to (for the community of modders at least).
• The interface calls to the engine are kept to the minimum, I haven't seen any performance loss worth the mention (at least in few numbers).
• Easily extendable.
• Can be later (or never as elexis says :P) move to C++ if someone stills feels itchy.

Regardless of the above, I wonder if this is the first such feature for which we are popping an object at runtime from the global nether. That seems like a different direction from our current GUI items.

Added to global.xml to minimize friction and maximize usefulness (having to add a resize bar xml definition in each page folder seems suboptimal though with a c++ implementation this could be entirely omitted)

If we have this in JS and it's not ideal but it works well enough, people who would have written c++ will do something else

If it's not ideal in JS, then someone should write it in C++, so the people who would have written it in C++ should be incentivized to do that, rather than deincentivized to?

and overall we'll have more features. That could be better.

Stacking problems usually ends up in convolution and our task is to solve problems, not to make more of them.
So the question is which parts of the code are a defect to have in C++ and which not.
If it's good in JS, then it'd be wrong to have it in C++ (rather than a tolerable evil).

In D1825#77564, @nani wrote:

If you want a reason as to why I've written it in Javascirpt:

• It was originally written for my mod, so asking people to compile 0ad just for this wasn't an option.

I know, but it does not follow from that that it's the right thing to do for Pyrogenesis.

• For all intended purposes works just as fine as a C++ implementation.

All intended purposes of alpha 23, but also all intended purposes of the Pyrogenesis engine (i.e. all mods, all future use cases too)?
As wraitii says, we might add a lot more complexity later.

• Is faster to change if needed to (for the community of modders at least).
• Easily extendable.

That's a full +1 for JS, that's why Pyrogenesis uses JS to begin with.

• The interface calls to the engine are kept to the minimum, I haven't seen any performance loss worth the mention (at least in few numbers).

Depends on a hypothetical C++ implementation. I imagine it might be possible to create a resize-bar or drag GUI Object type that only needs to be defined in XML and then has zero interface calls (in particular no onTick events).

• Can be later (or never as elexis says :P) move to C++ if someone stills feels itchy.

The question is what the ramifications are of making it in JS vs C++, what use cases are conceivable (not only the one use case we have now, but a class of use cases), whether it will be a step into the right direction or a step into the wrong direction which happens to cover all use cases we have now.

We might want to take a look at how other GUI engines support resize elements instead of reinventing the wheel.
(Btw you spoke about the idea of supporting a HTML/CSS engine, I've seen Philip had the same idea too, but I forgot where it was mentioned, and it will consume several weeks to months of work to transform everything.)

Anyhow, if JS was good, we may consider defining GUI object types in JS instead of C++, i.e. one could add <object type="myJSPrototype".... At least if we can conceive the creation of more than one JS GUI Object type.

In D1825#77563, @wraitii wrote:

Regardless of the above, I wonder if this is the first such feature for which we are popping an object at runtime from the global nether. That seems like a different direction from our current GUI items.

I think if we want resizable and movable dialogs, then most of them should be? For example the diplomacy dialog and chat window. Having two resizers on the same GUI page is not so remote.

(Also, a screenshot might illustrate the use case to the users who didn't test the patch stack.)