Rename "QVariant", "QVariantList", and "QPoint" attribute type names to "Variant", "VariantList", and "Point"

[Stinkfist0]

Qt names and classes are not naturally used f.ex. in the web client and possible other non-Qt-based Tundra implementations so more general type names would make sense.

[jonnenauha]

Hmm, so the only difference between float2 and QPoint is that qpoint is real? Could we make it real2 or int2 instead of QPoint. I think I added QPoint to hint that its a x,y and QSize to hint its width,height. This was a silly thing really to make our editor show "width" and "height" to give the user some idea what the units he is putting it has to do with the functionality. A more natural fit would of course be that the shown editor lables coul be put into the attributes metadata and make our QProperty editor get those labels from there.

[Stinkfist0]

Actually QPoint uses integers (QPointF uses qreal (typedef for either float or double)), int2 wouldn't sound too bad IMO.

[Stinkfist0]

Bump, as this is quite relevant now due to Tundra-Urho3D work. I'll try to cook up something in the near future. @cadaver @jonnenauha If you think the name should be something other than "Point", let me know.

[jonnenauha]

Are you sure we want to touch this? Wont this break pretty much everything on the network front reg. these types embedded to ECs and scripts creating DCs in code?

How are you planning to do this without breaking backwards compatibility? I don't see this as so important that we should make another protocol version bump and all the code to handle it. I mean tundra2 is still Qt/QVariant based, does not mean we should use Q prefixes but does not make the name incorrect either :)

I'd somehow prefer this gets handled on the tundra-urho3d client? It can freely rename the types without breaking anything (probably need some nasty code on the read attribute code though).

[Stinkfist0]

Naturally backwards compatibility will be retained.

[jonnenauha]

Yes, but I'm asking how are you planning to do this :) I would be interested if you can give an overview.

[Stinkfist0]

Network deals with type IDs instead of types names, so the solution will probably be quite simple.

[jonnenauha]

Code creates attributes by the name ent.dynamicComponent.CreateAttribute("mylist", "QVariantList");

You need some kind of deprecated type names check in those places. Probably sufficient to do it in SceneAPI::CreateAttribute?

[Stinkfist0]

SceneAPI::AttiributeTypeIdForTypeName is probably the only function that needs to be modified.

[Stinkfist0]

Was gonna push that first to Turho, but oh well. I tried to keep the change as minimal as possible , so it's a bit naive (every Q-prefixed type name goes) but @cadaver gave his blessing for this on IRC.