After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 499569 - Minus does not work correctly
Minus does not work correctly
Status: RESOLVED NOTABUG
Product: metacity
Classification: Other
Component: themes
2.20.x
Other Linux
: Normal minor
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2007-11-25 17:17 UTC by Benjamin Berg
Modified: 2007-11-26 20:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benjamin Berg 2007-11-25 17:17:42 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.
Comment 1 Thomas Thurman 2007-11-25 21:48:08 UTC
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?
Comment 2 Benjamin Berg 2007-11-25 22:28:02 UTC
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.
Comment 3 Havoc Pennington 2007-11-26 19:50:32 UTC
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)
Comment 4 Thomas Thurman 2007-11-26 20:21:55 UTC
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.
Comment 5 Havoc Pennington 2007-11-26 20:36:29 UTC
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...