Quote:
|
Going to have to disagree with you on this one. By allowing what you are requesting, you are limiting compatibility between different UIs, and basically gives the end user a work around for sloppy programming.
|
Not sure why you think that this would cause problems between different UIs.
If the people creating the UIs use reasonable naming conventions, (which they have to do currently to avoid conflicts) allowing overloading shouldnt change anything.
e.g. Fred creates his super ui and adds a new gauge, calling it FredGauge and puts it in a casting window.
Then Bill creates a gauge and calls it BillGauge and puts it in the breath window. No problem.
However if both Fred and Bill modified one of the default UI gauges there could be problems. But having overloading would not make this any worse.
Quote:
For example,
Bars.xml has the casting gauge in it. What is the person is using Turlo's Casting Window? All of a sudden, you have two casting guages in the same directory. The result would cause it to crash to desktop, and well it should.
|
This is a problem with the current setup so I'm missing the point?
What should happen would be the Bars.xml would have a casting gauge, named BarsCastingGauge, and the Turlo's casting window would have a gauge named TurlosCastingGauge (for example).
What my suggestion would allow would be to have, for example, if you wanted to change a single element that is contained in one of the large .xml files, you could simply have that element in your custom UI and not have to worry if the default UI changed something else in that file.
Does that make things clearer ?
Ang.