Tus comentarios
Definitely will be doing once I get a bit more of the core functionality I want in place and stabilized, and tidy up the code a bit -- still got a lot of //TODOs floating around ;)
Without making any guarantees I am projecting to open the code in 3-6 months.
Marking as PLANNED. Currently thinking this would work well as a series of small colored boxes that appear next to the "Highlight" context menu item, plus options to let you customize which colors appear in those boxes from the options page.
The hotfix for this is now up. As I am unable to reproduce the problem here I can't be sure that the actual cause has been fixed, but I've done everything I can think of to avoid and/or recover from this type of problem in future.
---
My sincere apologies. I am also going to try to release a 'hotfix' to specifically address this issue ASAP.
I see what you mean.
I've got a couple possible approaches that could solve this problem which I'll need to experiment with. The main cleverness that is needed here is a good UI mechanism for letting a user choose where they want to drop something in the "bottom of a branch" scenario.
The hotfix is now completed and I will most likely release it tomorrow as long as I don't find any other issues or new causes of the tree-emptying issue.
One last note - the next major release which I have been hammering on for the past month adds a "Recently closed" sidebar pane, so that will provide one more disaster-recovery mechanism for Sidewise when it's released.
Thanks for the report.
Unfortunately the only way I can suggest for recovering what you already lost is to recover the following folder from a local system backup, if you can:
C:\Users\<username>\AppData\Local\Google\Chrome
If you have such a backup from before "the incident", recovering that folder then restarting Chrome should bring the data back.
I am testing the hotfix now, which includes several changes to hopefully prevent this from happening ever again.
Although I cannot reproduce the issue here, the most likely cause is that Chrome sometimes fails to notify Sidewise about it shutting down, or takes a long time to do so. This could lead Sidewise to erroneously remove window(s) from the tree, thinking that the user manually closed a specific window and wanted it removed from the tree. Sidewise then saves this updated tree before Chrome finishes shutting down, so the tree turns up empty on restart.
That being said, I'm trying multiple overlapping strategies for addressing the emptied-tree issue in the hotfix:
- Increase wait time after closing a tab or window before allowing Sidewise to save the tree: this should directly counteract the "slow shutdown" case described above
- Never save the page tree to disk when it is currently empty
- Try harder to check for whether Chrome is shutting down before allowing saving of the page tree
- Automatically save an internal backup of the page tree every 15 minutes; if the page tree somehow comes up empty on restart and a backup exists, it will be automatically restored
- Add a "Recover tree from backup" button in Options->Advanced to manually restore the tree to the last internal backup saved during the *previous* Chrome session
Do you use Chrome's "Continue where I left off" setting, or one of the other two?
My sincere apologies. I am also going to try to release a 'hotfix' to specifically address this issue ASAP.
Servicio de atención al cliente por UserEcho
Do you find this happening reliably with any specific urls?