Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Octgn Deck Builder: Grouping Feature Request #1935

Open
SerbiusPrime opened this issue Apr 8, 2020 · 2 comments
Open

Octgn Deck Builder: Grouping Feature Request #1935

SerbiusPrime opened this issue Apr 8, 2020 · 2 comments
Assignees

Comments

@SerbiusPrime
Copy link

SerbiusPrime commented Apr 8, 2020

Add the ability to group cards in a deck by type for sorting and deckbuilding.

You can currently toggle between "Manual" and "Sorted"

Sorted currently sorts all cards from A-Z by Name.

Add another button when sorted is selected that toggles through column headers from the searchable card database and can be selected to toggle between options to use for sorting.

[Sorted] by [Name/Type/Color/Set/Rarity/ect]
Example

@brine
Copy link
Contributor

brine commented Apr 22, 2020

assigning this to the deck editor master. Should be able to do this in a game-generic way?

@BenMatteson
Copy link
Contributor

the current system uses the built-in sorting that simply sorts on a column in the table, this is to avoid reordering the "manual" ordering of the cards, so sorting by a value not in the table is a lot more work.

it should be possible to override the sorting event and use a custom comparator defined by the selected card property, basically allowing the concept proposed in the example. this would need to be made to play nice with the sorting options in the column headers, or they would need to be disabled.

alternately, I looked into adding a third column to the table that could be assigned to any of the other properties, but currently there's no good way to bind to the properties of a multicard, so it would need to be populated manually.

In theory I prefer the second approach as it gives better feedback on the sorting and should be more reliable if the values can be properly bound, but currently requires more square-peg-in-a-round-hole than I want to deal with. As for the proposed approach, I'm not really sure I like it from an interface standpoint, but I may look into later if the alternative is still ugly after some pending changes to the way the properties are accessed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants