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.

Sign up for GitHub

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

Jump to bottom

Implement Subsplits #168

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft

Implement Subsplits #168

wants to merge 7 commits into from

Conversation

CryZe
Copy link
Collaborator

@CryZe CryZe commented Feb 21, 2019 •
edited
Loading

This is a work in progress implementation of Subsplits. Instead of encoding the subsplits information into the segment names we extend the run format properly so the subsplits information can be stored. This is the roadmap for this Pull Request:

  • Parse the original modified segment names and rewrite them to be normal segment names.
  • Store the subsplits information in the Run structure
  • Extend the splits component to handle the additional subsplits information.
    • Implement basic support for subsplits.
    • Extend the "always show all splits" option to precalculate the maximum size necessary.
    • Add columns to the opened group headers.
    • Add setting for keeping previous group headers scrolled in.
    • Implement focus changing manual scrolling (scrolling should be able to open up other groups).
    • Handle columns that are based on relative times (such as segment times) on collapsed group headers. (e.g. it should be the combined segment time of the whole group, not just of the last segment in the group). Also add a test for this.
  • Extend the splits format to store the subsplits information.
  • Parse the subsplits information from the splits format.
    • Empty group names are the same as non-existing group names, this doesn't match the behavior elsewhere.
    • What to do about out of range groups?
    • There could be a group that is directly at the end such that it returns a view with an empty slice. That breaks a few assumptions.
  • Extend the Run Editor to support the subsplits.
  • Add Documentation.
  • Add Tests.
    • Make sure the final split doesn't scroll the window back to the beginning.
  • Improve horizontal support (such as the indentation not really making too much sense maybe)

Closes #36

@CryZe CryZe added the enhancement An improvement for livesplit-core. label Feb 21, 2019
@CryZe CryZe added the feature A new user visible feature for livesplit-core. label Apr 15, 2019
CryZe
CryZe commented Apr 25, 2019
View reviewed changes
capi/bind_gen/src/typescript.ts
/**
* Describes whether the row should be considered an even or an odd row.
* This is useful for visualizing the rows with alternating colors.
*/
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This talks about rows, but in horizontal, we don't even use rows.

@CryZe
Rewrite Subsplit segment names while importing
6cf2799 
For now all the subsplit information is discarded to the point where
only normal segment names are left.
@CryZe
Store segment groups in Run
3d7736d 
The individual subsplits sections are now called segment groups that now
exist in the individual form of the SegmentGroup and combined form of
the SegmentGroups type. The groups are stored in the Run.
@CryZe
Add an iterator over the segment groups
ed6d972 
Dealing with the index based group ranges is not ergonomic. Therefore
this commits adds an iterator that returns all the groups as views of
segment slices. Also segments that are not part of any groups become
pseudo-groups of single segments. The splits component should be able to
build on top of this.
@CryZe
Add Basic Subsplits Support in Splits Component
e1b9db2 
All the splits without any segment groups behave like they did before
and the segment groups now properly open up and close as they are being
entered. This is done by transforming the segment groups iterator and
implementing an iterator on top that flattens it with a specific segment
in focus that determines the group that is supposed to be open. After
this flattening almost all the original logic remains, but now with the
current segment index and the run's length instead being based on this
flattened segment group representation.
@CryZe
Save Segment Groups into the splits files
6b564d9 
It seems like we should have them as a separate block in there, such
that old parsers will have no problem simply ignoring that new block and
parsing the splits regardless. This however has the disadvantage that
the groups can now overlap, which we will have to account for when
parsing.
@CryZe
Implement parsing the segment groups
13ca38c 
Parsing the segment groups works now and it automatically makes sure the
ranges are sorted and don't overlap. There are two remaining problems
here though. One is that the group name doesn't differentiate between
being empty and not existing here. I don't think we want to
differentiate those two case long term anyway as it doesn't make much
sense in the Run Editor to do so either. The other problem is that it
parses segment groups right now that may be out of the total amount of
segments' range. That shouldn't cause any major problems, but those
ranges probably don't interact well with the Run Editor, so we need to
be wary of that.
@CryZe
Bump lss version to 1.8.1
45365e1
@CryZe CryZe added the stalled The work is not making any progress. label Jun 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement An improvement for livesplit-core. feature A new user visible feature for livesplit-core. stalled The work is not making any progress.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Implement Sub Splits into Splits Component
1 participant
@CryZe