Hey,
This is actually a by far tougher change than I thought it was. I am, however, entirely sure that this is worth it. The caret bothers me since you brought it up. It is like a painting that is hanging slightly rotated and once someone has pointed it out to you, you can't unsee it
![Hammer :hammer:](./images/smilies/hammer.gif)
And in that case, what you want to do is fix it, so it doesnt bother you anymore. So lets try to accomplish that.
I am trying to find an existing example of similar usage so that we can follow it. So far what I found out is that these properties are all linked to actual values inside classes so I was wrong, you would have to add a member. Unless you used a PropertyDefinition. For that case,however, the performance is not as good and the access is indirect plus you cannot be sure inside the class that the LNF defines this, whereas the macro defines it directly from within the class- an arguably better solution. Now here comes the bummer: We can't add new members to classes in v0-8, this would break ABI compatibility. We can accept your changes for v0 though. which is the 0.9 Releases.
Here is my findings regarding the property stuff:
CEGUI_DEFINE_WINDOW_RENDERER_PROPERTY is indeed what we need
the first parameters for it are obvious, interesting are the last 3: setter, getter and default value. The default value for us can be "" afaik. The getter and setter can theoretically be left 0, it is also possibly to just have one of them be 0. In our case we want to set both though and we actually do wanna store the variable in a local variable like you did, i was wrong about what I said there, sorry for the confusion.
Bertram wrote:I thus added that member and made it so the value is stored and it went fine as is. I don't really have a clue of what I should do now, though.
It is fine, you did it right.
Bertram wrote:I did, and tested live in game. It is working. Or is the LNF something else than the xml file?
I meant as a <Property...> and see if it actually updates to the right cursor set in it, in read-only mode, and also see if it switches back. If your code works like that it is fine.
Ident wrote:If you took the idea of adding a member from another class please notify me where you saw this. I am aware that FalagardImage does this and this is a bug that will be resolved in 1.0.
I was wrong on this. While it is possible to replace some of the variables with property-only definitions, it doesnt make sense in any of the cases. The status-quo is fine. I will have to look into the StaticImage Image property though because I know we now have pure-LNF images and they seem to do fine.
Very important: if you make a PR it has to be based off the v0 branch. Changes between v0 and v0-8 are however minimal. They are compatible overall and all your function calls are equivalent. Only default branch will break anything so updating to v0 should pose no issue whatsoever.