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

save/restore of widget content #15

Open
robobenklein opened this issue Sep 25, 2022 · 3 comments
Open

save/restore of widget content #15

robobenklein opened this issue Sep 25, 2022 · 3 comments
Assignees

Comments

@robobenklein
Copy link
Member

https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/shell/application-shell.ts#L604

getLayoutData still contains unserialized widgets, so conversion happens outside the application-shell scope, therefore we need to be compatible enough with DockPanel that the outer code behaves the same.

https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/shell/shell-layout-restorer.ts#L156

getLayoutData from the AS is called by restorer

deflate: https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/shell/shell-layout-restorer.ts#L191

Assumes property names must match exactly widget or widgets by isWidget(s)Property...

Widget itself if stateful should provide storeState(), but looks like CR Patches will mostly be subject to the widget manager's whims: https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/widget-manager.ts

So in the end maybe a patch should not be reported as a first-class widget? (We could dig into it via our own serializer)

@robobenklein robobenklein self-assigned this Sep 25, 2022
@robobenklein robobenklein added this to the Stable Release milestone Sep 25, 2022
@robobenklein
Copy link
Member Author

went with this, patches are no longer serialized as widgets, but as our own serialize type and thus need some extra things to be implemented...

it's closer to the atom implementation, but I'll make some changes given this opportunity anyways

@robobenklein
Copy link
Member Author

a32c269

It's just the darn sizers at this point, and the restore function works perfectly fine after the main application view is ready, but not during the restoreLayout?

Clearly my own restoreLayout does what it intends:
image

After this, application goes from attached_shell to initialized_layout, so far so good, but then on the next IBL update:

image

And thus the sizer data is lost?

@robobenklein
Copy link
Member Author

Also probably related to the sizers problem, but scroll-position gets messed up after deserialize as well. Looking like something is adjusting the layout during the load process?

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

No branches or pull requests

1 participant