Closed Eein closed 1 year ago
cleaning up/refactoring modules is pretty much mandatory at this point, but this is a working MVP to test
the whole thing is likely to be thrown out and rewritten when we get an actual good terminal library. if you want to do further work in this regard though, i won't mind
theres some wonky error handling but it seems to work for most cases by consuming livesplit errors
cursive doesn't exactly make this easy. this library is actually garbage
i do alot of assignments for readability, if thats not desired let me konw
i actually prefer this as opposed to longer lines and deeper nesting
theres some performance issues still, need to dive deeper but its most likely just because i'm using LinearLayout for managing alignment
was this in a release build? debug builds are slows as hell
minimum 80 chars required to display entire ui (maybe a bit less)
this is fine
reused the yucky find_name, since it seems like the best way to handle layout rehydration without pulling away management of the state from livesplit-core
again this library is poorly designed so i'm not gonna be upset over this
let globals: GlobalState = s.take_user_data().unwrap(); rips out the current state so it cannot be used further in the loop if necessary it may be better to just use let globals = s.user_data::
().unwrap(); everywhere for sanity, unless the idea is to save and quit on save
current idea is to quit on save as you specify the file on the command line
future Livesplit core (0.13) requires two minor changes to be up to date
this is not an issue
i am not done reviewing this yet. there is likely more i need to look at
on the edit split menu, i would have a dedicated save button at the bottom instead of listening to the enter key press on the text field. it is extremely unclear how to save what you enter otherwise
UniqueId
in lib.rs
was designed to help with referencing fields. take a look at how i used it in the layout editor.
also my idea of mvp is to have most features available to edit
there is no way to add comparisons or goal times right now, and those likely should be added if its feasible
theres some performance issues still, need to dive deeper but its most likely just because i'm using LinearLayout for managing alignment
was this in a release build? debug builds are slows as hell
it was like 2 fps in debug builds - now with the changes its still slow, but not .5fps
Just a note for myself - need to add a real and game time toggle + additional info (metadata)
also my idea of mvp is to have most features available to edit
there is no way to add comparisons or goal times right now, and those likely should be added if its feasible
How are comparisons generally used? Imported from file or manually entered?
For file-based comparisons imports, I'd like to avoid making a file browser right now for this mvp and tackle it either later or in whatever system gets chosen in the future.
For manual additions, i'll just need to load in custom comparisons at the end and implement right scrolling or a larger size (if thats possible)
I can also revisit the rendering of splits when i get to these.
I am not too concerned about file import right now. Its a very niche feature that only really works under certain situations.
notes:
Most of it looks good although as of right now its impossible to change the split time. You might need to rework that menu entirely.
Most of it looks good although as of right now its impossible to change the split time. You might need to rework that menu entirely.
could have sworn it worked. i'll have a look
its here; it doesn't like how i'm changing things inline like this. maybe a data race?
i'll have to edit this as individual fields off a select view - it really doesn't want me to send this through like this
I suppose i could also wrap it and get all children at once. Lemme check examples
iirc livesplit_core will automatically update some of the times in order to fit certain constraints
if you attempt to update all of them at once, the thing you update last is going to get priority
i'll be out of town for work for a week - may have time to adjust this during that time, but maybe not - just a heads up
A little enter heavy to use, but its better than it was and the values seem to shift properly. Let me know what you think!
It is almost there. Only thing that's left is having the times properly refresh in the edit split menu, and then I'll merge it. Right now the other times do not update correctly at all there, especially if one action results in a lot of other times changing at the same time.
A little bit rudimentary but it works.
Let me know if there's anything else you'd like for me to change.
looks good for the most part
edit: you should probably add comparisons to that menu so they can be edited
after that it should be good to merge
edit: you should probably add comparisons to that menu so they can be edited.
I'm assuming goals are included here? Shouldn't be too big of a lift, it would be similar to how i render them, as long as i dont upset the borrow checker
Yeah a goal is just a normal custom comparison
I believe the last commit should get it working as intended :) :tada:
i'll get around to reviewing this on the weekend
Was testing today and gametime/realtime doesn't save.
edit: turns out this isn't relevant, since the layout handles this.
i completely forgot about this and im probably just gonna go ahead and merge it assuming it doesn't break anything else
Implements a rough splits editor; Planning a refactor soon, but wanted to get some eyes on things.
Note to onlookers: Please use a backup splits file if you plan on toying with this
TODO
take_user_data
on save and quitWont implement
Notable jank
add_splits
function does some strange padding jank to satisfy not having nestableLinearLayouts
due to a cache bugLinearLayout
for managing alignmentfind_name
, since it seems like the best way to handle layout rehydration without pulling away management of the state fromlivesplit-core
Things noticed
let globals: GlobalState = s.take_user_data().unwrap();
rips out the current state so it cannot be used further in the loop if necessary it may be better to just uselet globals = s.user_data::<GlobalState>().unwrap();
everywhere for sanity, unless the idea is to save and quit on save