GNOME Bugzilla – Bug 499569
Minus does not work correctly
Last modified: 2007-11-26 20:36:29 UTC
The minus does not work correctly. For example having x="-1" in a metacity theme does not work. x="0-1" works fine however.
This is by design. http://svn.gnome.org/viewvc/metacity/trunk/src/theme.c?annotate=3271 Line 1589: case '-': /* negative numbers aren't allowed so this is easy */ Line 2280-1: ... optionally "object_width" and object_height". Negative numbers aren't allowed. */ However, I note that the theme format documentation does not explain that negative literals are not allowed. This should clearly be fixed. Alternatively, we could modify the expression parser so that unary minus is permitted; can you explain why you would want negative literals in a theme?
To say the truth I am wondering myself why I needed a -1 there. <line color="FGNormal" x1="0-1" y2="0-1" x2="width" y1="height" width="LineWidth" /> With that I got the behaviour I wanted, not sure why it was wrong in the first place.
It does seem bizarre to allow "0-1" but not "-1", though. If negative is not allowed then "0-1" should not be allowed. (Though, throwing an error if an expression evals to negative might break things or require everyone to do "max(expression,0)" all the time... so it's possible all expressions should have an implicit floor of 0, rather than making it an error... not sure without digging into the code)
I'm not sure whether "negative numbers are not allowed so this is easy" means: 1) "This is easy, because we don't allow any number to be negative." (In fact, we do allow numbers to be negative, because as you note we can write 0-1.) I assume that, if this is the correct interpretation, it is short for "Interpreting the '-' symbol is easy, because we only allow dyadic subtraction, because we don't allow unary negation, because we don't allow numbers to be negative". So in this case, we have decided (for reasons unknown) that we won't deal with negatives, even though in practice we do allow them to slip by if people can generate them. We can either carry on as we are, or floor them, or throw an error if they occur (which will almost certainly break existing themes [*]). 2) "We don't allow unary negation in order to make the code here easier". "Negative integer literals" would be a fairly reasonable interpretation of "negative numbers", and in all cases where you would have a negative integer literal you would have unary negation, and in only those cases. In this case, we deliberately excluded negative literals in order to make the parsing easier, but we haven't decided we won't deal with ANY negative number. Therefore all the possibilities above apply, and also the possibility that we should introduce unary negation to make it possible to write negative literals. [*] I wonder whether we can get an enormous theme library together so that we can try parsing everything in it every time we change the parser.
Don't ask me ;-) I certainly don't remember what I meant, if I even wrote that comment ;-) I would recommend relying on the code and logic and ignoring the comment...