Conversation
0xar-ds
force-pushed
the
refactor/restrictions
branch
from
9ceeda5 to
bf74ec6
Compare
Collaborator
Author
|
Adopting lists |
Collaborator
Author
|
@mkram17 rendered: In restrictions config: In ruleset config: |
Collaborator
Author
|
Also, now that I think about it... If we adopt #73, rather than to have a user type-in the item to-be restricted, they could choose it from the picker |
Collaborator
Author
|
also lmk if you prefer the config to be like this |
mkram17
approved these changes
Mar 21, 2026
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Each SlotHighlight is now to own its cache (there was no shared computation nor shared api; to have a central cache was an abstraction which leveraged to nothing) and apply a simple interface which we could further elevate to require a annotated method, in that of to automatically handle this type of highlights on our mixin. Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
0xar-ds
force-pushed
the
refactor/restrictions
branch
2 times, most recently
from
ce1d470 to
0c4e5f8
Compare
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Each SlotHighlight is now to own its cache (there was no shared computation nor shared api; to have a central cache was an abstraction which leveraged to nothing) and apply a simple interface which we could further elevate to require a annotated method, in that of to automatically handle this type of highlights on our mixin. Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
…rictors Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Interface consumed by the library's ListScreen to render the title and, optionally, comment, of a entry of the rendered list. Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
Signed-off-by: 0xar-ds <sadden-rope-sleek@duck.com>
0xar-ds
force-pushed
the
refactor/restrictions
branch
from
0c4e5f8 to
fd232b0
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
depends on #85
Current sell restrictions is now a concrete of RestrictionHelper, a InputHelper-alike class which is generic enough as to also allow a SellSacksRestriction by barely providing the to-order-parsing api. The RestrictionHelper could be further utilized to implement Buy Order/Sell Order restrictions if deemed a wanted feature.
The configuration was refactored to encompass the generalization of restrictors: the "instant sell toggle" has become a global toggle for the API¹; and a enum was added to select which concretes are enabled, whereas each rule² may also select whether it is applied to that restrictor target/concrete.
I don't like how the config resulted but I would like to wait until ResourcefulConfig finally merges and releases the List support before merging this PR: each rule's "enabled" toggle will be dropped (its mere existence on the list will be considered as validity) and that of selecting/toggle whether a rule targets a restrictor should be of less clutter. Also we can move the toggle/separated group of options into that category then, for each type of rule will be a simple list. We can also then consider whether a "restrictor" is enabled by simply having rules scoped & the global toggle so we drop the concrete selection on the main screen as well.