-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Switched toolbox IDs to signed. (#76)
* Switched toolbox IDs to back to signed
- Loading branch information
Showing
21 changed files
with
204 additions
and
176 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
130384f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was the reasoning for changing the toolbox IDs back to signed values?
I have just been using release 1.10 and I think there the IDs are unsigned, but some of the code was passing them to SWIs using the "i" which is signed, so I was sometimes getting errors about the value being out of range for C long. Fo example, in gadgets/slider.py the colour.setter function had the SWI call with '0iiiii' but changing it to '0IIIii' solved the problem.
I would have expected the IDs to be held as unsigned values as they are essentially meaningless, but perhaps there are special values in some of the calls which are actually negative, so they all need to be signed?
Or maybe it was just easier to use signed values because more of the code was set up to expect that?
Just curious as it may help me understand the design better.
130384f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't speak for the maintainer, but there's been some back and forth on it and I believe most of the discussion is in these issues:
#75
#78
To attempt to sum it up, it was historically signed values before I used it, and that changed for 1.10 but I suggested it be changed back on the basis that it shouldn't matter as long as usage is consistent, and it was breaking any pre-existing code using the library (namely mine, admittedly). Additionally, I don't believe everything was fully switched to unsigned leaving a couple inconsistencies anyway and the C veneers use the signed convention. However, there hasn't been a tagged release since the switch back, yet. The latest code in main does change back to signed however (although there may still be parts that have been missed, as per some open issues).
130384f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that makes a lot of sense! Yes, as they are opaque values, consistency is the only thing that matters! I'm not so familiar with the Toolbox, but with the Wimp more generally there are certainly instances of window handles having special values such as -1 and -2 for the different ends of the iconbar, so if window handles need to be signed, making Toolbox handles signed as well will be consistent with that.
130384f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is an interesting point, there is at least one or two Toolbox SWIs that I can think of that can return Wimp handles as opposed to Toolbox IDs depending on if a flag is set, I'm not sure if that has any bearing on this but it could be something to consider.