Completely refactor and fix timeslider#2040
Conversation
This commit introduces a new TimesliderClient object which will
eventually handle all communication with the server in a sane fashion.
At the moment, minimal work has been done to wire the existing code into
this object. The current 'on("MESSAGE_TYPE")' model will change so that
the timeslider object is actually the one managing all the information,
instead of delegating it all out to callbacks.
This current version still works just as the stock version did.
The slider handle and stars render correctly. Not yet wired up to real events.
without this, the timeslider and sliderui classes don't work
Working slider class with mouse handling (click, drag) and events (change, slide). Lots of console logs still in the code. Got rid of some of the legacy code.
Also, the steppers actually work.
findPath works. transition requests changesets from server. processing of changesets works correctly. Only need to manage the async-ifying of transition, which is currently written as a while loop, (with a short-circuit break for debugging).
There are still some weird kinks in the traversal algorithm. For example, trying to go from 9 -> 19 fails very oddly.
There are still some bugs in the traversal algorithm, as well as bugs being triggered in the server. Also, for some reason it looks like there is a problem with the attribute pool not containing certain elements.
Working: - location.hash - click on slider - stepper buttons - UI update (except authors) Not working: - playback - bugs in transition code
Handle upstream new revisions and added users/authors.
Added HUGE (1000 revs) bucket. There are still some libchangeset errors which need fixing.
|
This is more or less ready. There are two outstanding issues with the changesets themselves, one of which must be resolved before we can move forward, as it leaves the pad in an unknown state: I'd be grateful for some additional testing. |
|
We have frontend automated tests for this already: peep the timeslider files in https://github.com/ether/etherpad-lite/tree/develop/tests/frontend/specs Hope that helps :) |
|
author colors are only visible as long as you don't change the revision. Newly applied changesets don't add author colors, it seems. |
|
And I get a lot of these, (especially when going back to rev#0) |
|
(regarding that occupying char (TM)): var changeset = require('ep_etherpad-lite/static/js/changeset.js')
changeset.applyToAText(
_this.revisionCache.head_revision.previous.small.value
, _this.clientVars.collab_client_vars.initialAttributedText
)The error is thrown at this line: Considering that the changesets received from the server are invalid, the timeslider shouldn't work at all. The timeslider code prolly uses some line based apply method, that gives its best to cover up such mistakes, so that's why it still works somehow. I suspect there's one |
|
Thanks for all the feedback. I'll probably only be able to do some more work on this tomorrow. The timeslider does do line-based changeset stuff. |
|
Just wrote some assertions on the server, and it seems the server-side code is broken. -- ahem.. maybe not, I dunno, it's all very confusing |
|
@marcelklehr let's try to debug together tomorrow? |
|
yea, let's see what we can do tomorrow. |
It now does partial findPaths, builds the final path as it goes and requests changesets for missing bits only.
|
The timeslider looks very good, but it seems very slow if you have multiple revisions and/or change very fast between them. Sometimes it hangs and take a while till it jumps to the selected revision. |
|
There are still a few bugs and changes that need to be fixed/made. I unfortunately haven't had much time to work on this in the last couple of weeks. Hopefully I'll have some time later this week. |
There was a problem hiding this comment.
I guess this was written with the assumption that the timeslider would run on the same page as the editor... (so, the editorbox would have to be moved down)
|
I guess this can be closed in favor of @marcelklehr 's pull request? cc @s1341 |
|
Closing as we have another PR that supersedes this~- Thanks to @s1341 for his work! |
No description provided.