[KevinH]

Hi,

After thinking about it, I am going to make the following changes to my Preserve Entities patch:

1. remove the edit button in the new preferences widget since the only way to add a entity will validate that the strings are proper to begin with, and the entities are short strings that should not need editing once set. So the add and remove buttons should be enough.

2. shrink the entity list widget down to some more reasonable width (given I can figure out how to do that) by hand editing the ui file

3. change just the SettingsStore to use the list of std:pairs of code and string so that constant hash-lookups are not needed. The Preferences widget will still just ask for a list of entities not codes, and XMLEntities will be used to add the codes when going to SettingsStore (and remove the codes when loading back into the Preferences widget).

I will work on a new patch that makes these changes.

I would still like feedback from anyone trying the version already posted if possible, in case there are other things that need changing.

Edit:

Well QSettings uses QVariant and no matter how hard I try QVariant can not seem to grok a QList of anything other than the types QVariant understands which unfortunately is not std::pairs. I could not even get it to work using typedefs. I would have to cast it to a void * blob and back which loses all type safety and causes problems. I guess QVariant is a union type of some sort that requires to at least grok the basic underlying types or structures it is working with.

I will simply have to store them as int lists and QStringList as two separate keys to get it to work.

Edit 2:

That did not work ... Even storing an QList <int> is an issue since what it is really storing is a QList <QVariant> (since QVariant needed by QSettings) and so it requires a lot of casts (which is a nightmare!) when trying to use a custom Type. I am sure there is a way to do it but all of the templates and things may confuse the preprocessors/compilers and be hard to read.

Then it hit me ... all of our codes are valid unicode code points so a List of ushorts can simply become a single QString and saved in SettingsStored in that way. And QSettings handles those just fine. So now I am using two keys in SettingsStore, one to hold the QStringList of entitiy names, and one to hold the QString of codepoints. I convert them to the QList < std::pair < ushort, QString > > for passing around and using them in the Clean routines.

So now the only time the XMLEnities is used is when they are added the first time, and only valid named/numbered Entities are ever added. With edit removed, I don't have to worry about people editing the values into something non-valid.

This approach also prevents this Preference being used as an attack vector using nested entities or any random user generated strings. That should be a good thing.