Feature: Implement NSPredicateEditor - #857
Conversation
Every method was a stub, so an editor had no rows, asked its delegate for nothing and produced no predicate. The editor now keeps its rows in a tree, walks the delegate for the criteria and display values a row starts out with, lays those out a row at a time, and builds a predicate from the parts the delegate gives for each criterion. The row a nesting mode calls for is made along with the first row it holds, and the rows of a list are joined with or.
Every method was a stub returning nil or zero, and the initialisers kept none of what they were given, so a template described nothing and could build no predicate. A template now holds its expressions, operators, modifier and options, builds the views for a row from them, reads a predicate out of those views, sets them from a predicate, and reports how well a predicate fits it.
The class held its row templates and coded them, but did nothing with them: it had no rows, showed nothing and produced no predicate. A row is now made from one of the row templates, a compound one for a row that holds others and a comparison one for the rest, and shows that template's views. The predicate of the editor is read back out of the rows, and setting a predicate on the editor makes the rows that display it, choosing for each part the template that fits it best.
START_SET creates an autorelease pool and END_SET releases it, so the pool these tests create around the set is redundant.
…-editor Tests/gui/NSPredicateEditorRowTemplate/basic.m was added on both sides. The copy on master is the one kept, because it uses the exception macros that replaced the hand written handlers.
|
I am concerned about this change as it crosses the line from a simple fix to implementing an entire feature. I am assuming, given that you used Claude to help do the other PRs, I am wondering... did you use it here? |
Hi Greg, fair question - but I must say I never realized the disservice I did to myself when I sent my original message to everyone about our Claude Code 4.6 audit back in April. 😄 For clarity, the only places any AI tools have touched either the PRs or the features in GNUStep from my contributions are:
Everything else are the usual suspects of ASan, TSan, valgrind, bash scripts, and copious use of Regex (I have a long-term situationship with Regex - don't tell my wife). With that preamble in place - this is all my code (good and bad) for this feature (my team didn't work on it, this was my personal contribution). The design spec was the Apple documentation for the public API, I wrote tests and ran it against an actual Apple runner to validate behavior, and then the rest of it was trial and error. I believe we are onside with the LLM policy you sent out a couple weeks ago - unless you feel the PR comments themselves need to be annotated, in which case, I will delete them and replace them with a directly crafted (and much shorter version) for each. |
NSPredicateEditor kept its row templates and coded them, but did nothing with them: it had no rows, showed nothing, and produced no predicate.
A row is now made from one of the row templates, a compound one for a row that holds others and a comparison one for the rest, and it shows the views of a copy of that template, so each row is edited on its own. The predicate of the editor is read back out of the rows, a compound row joining the rows beneath it. Setting a predicate on the editor makes the rows that display it, choosing for each part the template that fits it best and passing over a part no template can hold. An editor starts out with a template for the three compound types, as one made in a nib does, and its value is its predicate.
This is built on the two other pieces of #96 and holds their commits: NSRuleEditor #856, which it derives from, and NSPredicateEditorRowTemplate #855, which supplies the rows. It is ready once those are in.
Tests/gui/NSPredicateEditor/basic.m. 16 assertions fail before the change and pass after.
Closes #96.