BugFix: bad parsing of map room/exit sizes + tidy XML import/export c…#372
Conversation
…lasses Floating point numbers used for the 2D map room and exit-line sizes were included in the XML file format twice and being read as integers when one, at least, is a decimal number in range 0.1 to 1.1 so was being set to zero when read for 9 out 11 cases. The miss-spelt duplicate "commandSeperator" element is no longer written as the parsing code can handle an element missing when reading the Host part of the XML file. The XMLimport class will silently ignore the above duplicate details so as to avoid producing qDebug() messages about them when reading them in XML files produced from older code. I have taken the opportunity to clean up the code layout in these two classes, the XMLexport had some code block indentation issues and the XMLimport class some pointless if() code. I also have added in error detection/reporting code in the export code so that if errors arise in method function calls they are reported up the caller chain and the XMLWriter aborts as soon as an error is detected. I have also added QDebug() reporting for all instances where lua scripts are inserting into the Mudlet items as they are loaded where they were only previously being done for some types of item. It was also possible to eliminate the redundant (QString) XMLexport::mType member and the unneeded XMLexport(Host *, bool) C'tor. I also renamed: * (void) XMLimport::readMapList(QMap<QString, QStringList> & ) ==> (void) XMLimport::readModulesDetailsMap(QMap<QString, QStringList> & ) to reduce any confusion over what it applies to (a QMap not the profile's Map!) I have held off on applying QStringLiteral(...) wrappers around all the string literals in these classes as that would just make the change-set even larger on this occasion but it is something to be done at a later stage IMHO. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…e_30"
I note I had some details incorrect or not completely done when porting the
bug correction bits to the other "release_30" active branch. Also some
comments were worth revising so that they match ones left in that branch.
* Removed misspelt "commandSeperator" sub-element of the "Host" element
and the associated (QString) Host::mCommandSeperator which was unused
and duplicated the (QString) Host::mCommandSeperator member...!
* Tweaked some QDebug() message texts for a uniform style and to correct
some amendments missed when they were copied from one method to another.
* Added an argument to the XMLimport::readIntegerList(...) to pass the name
of the parent trigger for use if/when the error condition of having an
invalid (not a number) as an element that encodes the type of the trigger
condition for a particular condition. This is justified because under
those conditions qFatal() is used {probably because it is the only QDebug
class method that WILL be detectable on a WINDOWS platform for a RELEASE
build} unfortunately it will KILL the Mudlet application - so it behoves
Mudlet to report what killed it when it does die through this!
* Tweaked some comments to match versions in the release_30 bug_fix only
version of this Pull Request.
* Rename the argument to void XMLimport::readHostPackage(Host *) from pT
to pHost as the latter name is more prevalent elsewhere in the
application.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
| writeEndElement(); // </HelpPackage> | ||
| } | ||
|
|
||
| // writeEndElement();//end hostpackage - NOT NEEDED HERE! |
There was a problem hiding this comment.
This does seem surplus to requirements...
| } | ||
| writeEndElement(); // </mInstalledModules> | ||
| } | ||
| // CHECK: Do we need: |
There was a problem hiding this comment.
I guess not as our reader code gets along quite nicely without a <mInstalledModules>...</mInstalledModules> segment...
| if( isOk ) { | ||
| writeStartElement("TriggerPackage"); | ||
| for( auto it = pHost->mTriggerUnit.mTriggerRootNodeList.begin(); isOk && it != pHost->mTriggerUnit.mTriggerRootNodeList.end(); ++it ) { | ||
| if( ! (*it) || (*it)->mModuleMember) { |
There was a problem hiding this comment.
Here and elsewhere in similar code I got rid of a temporary variable (which had to be of the specified type) so we could take more advantage of the C11 auto keyword - minor niggle is the current Qt IDE does not detect the type for members/methods used on the auto'ed variable to do the correct highlighting for them! 👼
| } | ||
| } | ||
|
|
||
| if( pT->exportItem ) { // CHECK: doesn't it also need a "&& (! pT->mModuleMasterFolder)" |
There was a problem hiding this comment.
I am suspicious of the absence of the second term... 😕
| void XMLimport::readVariableGroup( TVar *pParent ) | ||
| { | ||
| TVar * var; | ||
| if( pParent ) |
There was a problem hiding this comment.
This construct is used for each of the Mudlet Item types but it is pointless and refactors down to the single line I've used!
See Tree.h and the individual item constructors...
src/XMLimport.cpp
Outdated
| // Using qFatal() seems a little, erm, fatalistic but | ||
| // it seems no lesser one will always be detectable on the | ||
| // RELEASE version on Windows? - Slysven | ||
| qFatal( "XMLimport::readIntegerList(...) ERROR: unable to convert: \"%1\" to a number when reading the 'regexCodePropertyList' element of the 'Trigger' or 'TriggerGroup' element!", |
There was a problem hiding this comment.
🪲 Bother should have used %s not %1 as it is a printf() format specifier not a QString::arg() replacement value - also missing a second %s for the parentName.
|
"lua scripts are inserting into the Mudlet items as they are loaded where they were only previously being done for some types of item." what do you mean by this? |
|
Since you have done so many formatting changes on the files - have you done this using the clang-format? If not, could you apply the src/.clang-format formatting? |
I may have got the expression wrong but for some item types (actions/aliases/keys/scripts/timers/triggers) the "script" element is now inserted into the application's memory at the end of parsing all the details about that item (using the I could have worded that better. I had forgotten about |
vadi2
left a comment
There was a problem hiding this comment.
Looks good, just run the files through clang-format (clang-format -style=file -i XMLimport.cpp, I think)
| if( isOk ) { | ||
| writeStartElement("TriggerPackage"); | ||
| for( auto it = pHost->mTriggerUnit.mTriggerRootNodeList.begin(); isOk && it != pHost->mTriggerUnit.mTriggerRootNodeList.end(); ++it ) { | ||
| if( ! (*it) || (*it)->mModuleMember) { |
| writeAttribute( "isColorTriggerFg", pT->mColorTriggerFg ? "yes" : "no" ); | ||
| writeAttribute( "isColorTriggerBg", pT->mColorTriggerBg ? "yes" : "no" ); | ||
|
|
||
| { // Blocked so that indentation reflects that of the XML file |
| { | ||
| pT->mLineSize = readElementText().toDouble(); | ||
| else if( name() == "mLineSize" || name() == "mRoomSize" ) { | ||
| // These two have been dropped from the Xml format as these are |
There was a problem hiding this comment.
This comment is a bit unclear - mLineSize and mRoomSize are still saved, just elsewhere, aren't they? (I've tested and they are)
…format
Had used QString argument replacement specifier (%1..%99) instead of C
printf() one (%s) for error message.
Also used clang-format on the class as per Vadim's suggestion. I also
added the already present ./src/.clang-format file to the Qt project file
so that it is visible within Qt Creator environment. I was unhappy with
some of the settings and revised/amended them:
It was necessary to use "//clang-format off" and "//clang-format on" around
the special pre_guard.h and post_guard.h headers needed to allow the use
of some memory checking facilities available on the Windows Platform using
the MSVC suite as without them these headers that themselves provide a
barrier around some DECLARATIONS and other needed bits within those two
files are re-positioned to BOTH be before the needed Qt libraries headers
files whereas they need to straddle just THOSE headers...
* ColumnLimit: 200 ==> 120
I try to ensure error messages that are sent to the user in the Lua
environment are limited to 80 characters which usually needs more than
80 columns to lay multi-line messages out within the code as they would
on screen (using a hanging indent for the code that leads up to a string
itself, however 200 characters is wider than I would like to go even on
my widescreen monitors equipped development platform. I choose 120 as a
reasonable compromise...
* ConstructorInitializerIndentWidth: 4 ==> 0
0 was what we had used in the past with manual formatting and it does not
seem necessary to change that.
* BreakBeforeBraces: Linux ==> Stroustrup
"Linux" compacts the "else" to be on just one line with the preceding
AND the succeeding braces on the same line, I had got used to the closing
brace being followed with a line break with the "else" and the following
opening brace on the next line and in line with the related "if" which I
thought we had adopted.
* SpacesInParentheses: false ==> true
pacesInSquareBrackets: {omitted} ==> true
Although it takes up more columns I prefer to have white space between
braces/brackets and the things they are wrapped around, it makes it
a little easier to visually pick out the parameter/arguments enclosed
- especially if I do not have the right spectacles on...!
* BinPackArguments: {omitted} ==> false
If we are adding or removing arguments from a function call it is easier
to "diff" pick out items if they can be laid out individually on their
own line (it can also leave space for short comments about arguments).
* PointerAlignment: Left ==> Middle
Whilst the left alignment emphasises that the type being declared is a
pointer or reference, the right more closely matches the case where the
variable is used. I prefer the middle case which favours neither but
flags that the item is not a plain variable... I realise that this is one
that perhaps the most contentious change I have made here!
* AllowShortCaseLabelsOnASingleLine: {omitted} ==> true
I am aware of several cases, particularly in the map drawing code
where single line case label and statements make the choosing one
set of settings from a group of them easier on the eye (and take up
less lines on screen) with an increase readability IMHO as a result.
* AlignConsecutiveDeclarations: {omitted} ==> true
Improves readability in header files IMHO.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
@vadi2 I've only used clang-format on the XMLimport class files, is that good enough for the moment? |
|
I'm sure that was an accident but sneaking in changes to the formatting options we've all agreed just because you think different now on like that is really poor taste. It should be a separate PR to change them... if it's really necessary... |
vadi2
left a comment
There was a problem hiding this comment.
Requesting changes as changing the code formatting options in a PR that's about improving parsing of some settings is way outta scope.
|
@vadi2 Where should the |
…mport The modifications I made to the file used to control the action of clang-format needed to be undone and then used for a re-run on the files affected (the XMLimport class ones). By comparison to the release_30 (the Mudlet 3.0 release) branch this branch stores the same config file in the ./src sub-directory compared to the parent directory that the other branch uses. A revision to the QMake project file ./src/src.pro was needed to display the file in the Qt Creator IDE as I had put in the location for the release_30 version in error in the previous commit. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
OK, my modifications to ./src/.clang-format has been undone - and the beautifier re-run on the I have to say that from my recollections of the discussions on code styling we had in the past I am not certain that we ever finalised on some of the settings - it was more that Ahmed moved away from (or got weighed down by other aspects of) the Mudlet project before we nailed it all down. There are some aspects of the results that I am not wildly keen about but that is something for, as you say, another PR... 😐 |
In Mudlet#372 (and a related PR for release_30 branch) [bug 1670825](https://bugs.launchpad.net/bugs/1670825) was found. I think it might be that the change uncovered something that was already at fault and this commit should address that. This needs testing to see if it cures the matter. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
In commit-a7f81aafd9897cf38137f22638bfc3bca4d9f0d5 (Pull Request Mudlet#372) a change was made that reordered the compilation of the Lua scripts for Mudlet items. This commit reverts that aspect to restore the compilation of parent (e.g. folder/container) items before their children. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
In commit-a7f81aafd9897cf38137f22638bfc3bca4d9f0d5 (Pull Request #372) a change was made that reordered the compilation of the Lua scripts for Mudlet items. This commit reverts that aspect to restore the compilation of parent (e.g. folder/container) items before their children. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Got the arguments for a qFatal() call wrong. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Mudlet#372) * BugFix: bad parsing of map room/exit sizes + tidy XML import/export classes Floating point numbers used for the 2D map room and exit-line sizes were included in the XML file format twice and being read as integers when one, at least, is a decimal number in range 0.1 to 1.1 so was being set to zero when read for 9 out 11 cases. The miss-spelt duplicate "commandSeperator" element is no longer written as the parsing code can handle an element missing when reading the Host part of the XML file. The XMLimport class will silently ignore the above duplicate details so as to avoid producing qDebug() messages about them when reading them in XML files produced from older code. I have taken the opportunity to clean up the code layout in these two classes, the XMLexport had some code block indentation issues and the XMLimport class some pointless if() code. I also have added in error detection/reporting code in the export code so that if errors arise in method function calls they are reported up the caller chain and the XMLWriter aborts as soon as an error is detected. I have also added QDebug() reporting for all instances where lua scripts are inserting into the Mudlet items as they are loaded where they were only previously being done for some types of item. It was also possible to eliminate the redundant (QString) XMLexport::mType member and the unneeded XMLexport(Host *, bool) C'tor. I also renamed: * (void) XMLimport::readMapList(QMap<QString, QStringList> & ) ==> (void) XMLimport::readModulesDetailsMap(QMap<QString, QStringList> & ) to reduce any confusion over what it applies to (a QMap not the profile's Map!) I have held off on applying QStringLiteral(...) wrappers around all the string literals in these classes as that would just make the change-set even larger on this occasion but it is something to be done at a later stage IMHO. Signed-off-by: Stephen Lyons <slysven@virginmedia.com> * Revise: further fixes revealed when porting BugFix portion to "release_30" I note I had some details incorrect or not completely done when porting the bug correction bits to the other "release_30" active branch. Also some comments were worth revising so that they match ones left in that branch. * Removed misspelt "commandSeperator" sub-element of the "Host" element and the associated (QString) Host::mCommandSeperator which was unused and duplicated the (QString) Host::mCommandSeperator member...! * Tweaked some QDebug() message texts for a uniform style and to correct some amendments missed when they were copied from one method to another. * Added an argument to the XMLimport::readIntegerList(...) to pass the name of the parent trigger for use if/when the error condition of having an invalid (not a number) as an element that encodes the type of the trigger condition for a particular condition. This is justified because under those conditions qFatal() is used {probably because it is the only QDebug class method that WILL be detectable on a WINDOWS platform for a RELEASE build} unfortunately it will KILL the Mudlet application - so it behoves Mudlet to report what killed it when it does die through this! * Tweaked some comments to match versions in the release_30 bug_fix only version of this Pull Request. * Rename the argument to void XMLimport::readHostPackage(Host *) from pT to pHost as the latter name is more prevalent elsewhere in the application. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…lasses
Floating point numbers used for the 2D map room and exit-line sizes were included in the XML file format twice and being read as integers when one, at least, is a decimal number in range 0.1 to 1.1 so was being set to zero when read for 9 out 11 cases.
The miss-spelt duplicate
"commandSeperator"element is no longer written as the parsing code can handle an element missing when reading the Host part of the XML file.The XMLimport class will silently ignore the above duplicate details so as to avoid producing qDebug() messages about them when reading them in XML files produced from older code.
I have taken the opportunity to clean up the code layout in these two classes, the
XMLexporthad some code block indentation issues and theXMLimportclass some pointlessif(...)code. I also have added in error detection/reporting code in the export code so that if errors arise in method function calls they are reported up the caller chain and theQXMLStreamWriteraborts as soon as an error is detected. I have also addedQDebug()reporting for all instances where lua scripts are inserting into the Mudlet items as they are loaded where they were only previously being done for some types of item.It was also possible to eliminate the redundant
(QString) XMLexport::mTypemember and the unneeded
XMLexport(Host *, bool)C'tor.I also renamed:
(void) XMLimport::readMapList(QMap<QString, QStringList> & )==>
(void) XMLimport::readModulesDetailsMap(QMap<QString, QStringList> & )to reduce any confusion over what it applies to (a
QMapnot the profile's Map!)I have held off on applying
QStringLiteral(...)wrappers around all the string literals in these classes as that would just make the change-set even larger on this occasion but it is something to be done at a later stage IMHO.Signed-off-by: Stephen Lyons slysven@virginmedia.com
P.S. I would suggest this is applied before #369 and I will extract the bug-fix part only for application to the release_30 branch...