Makes possible to change some XML object size with the mouse a.k.a resize.
Has animations included but can be removed with ease.
It's easy to add to the current codebase and adds minimum complexity.
Depends on D1702
Differential D1825
Resize (XML object) bar JS GUI addon nani on Apr 14 2019, 12:19 AM. Authored by
Details
Makes possible to change some XML object size with the mouse a.k.a resize. Depends on D1702 No real test, just see it works.
Diff Detail
Event TimelineComment Actions @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)?
Comment Actions 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. Comment Actions 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.
Comment Actions
Is C++ the correct place to implement the feature idea or not? Comment Actions 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. 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...)
Comment Actions
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.
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. Comment Actions If you want a reason as to why I've written it in Javascirpt:
Comment Actions
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) Comment Actions
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?
Stacking problems usually ends up in convolution and our task is to solve problems, not to make more of them. I know, but it does not follow from that that it's the right thing to do for Pyrogenesis.
All intended purposes of alpha 23, but also all intended purposes of the Pyrogenesis engine (i.e. all mods, all future use cases too)?
That's a full +1 for JS, that's why Pyrogenesis uses JS to begin with.
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).
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. 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. 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.) |