Ваши комментарии
I have identified a couple spots in the code that I think could be causing the missing-tab problem and am currently testing a fix for these. If my solution is correct, it will no longer be possible to "ever" wind up with missing tabs in the tree.
Sorry to hear the new version isn't working well for you. Unfortunately I haven't encountered the missing-tab problem you describe so I'm at a bit of a loss to help as of yet. One thing that may help is to just reload the extension -- I have a suspicion that that will restore those missing tabs to the tree and it should behave properly after that (hopefully).
As you say, Sidewise should control Chrome's tab order: that is the main new feature of the new version. Unfortunately it sounds like it isn't working right for you, but the intention was that the tab order should stay perfectly in sync between Chrome's tab bar horizontally and Sidewise's tree vertically. Currently Sidewise is set up to respect Chrome's tab ordering initially, and then if you move stuff around in the tree, reorder Chrome's tabbar accordingly (and vice versa).
I'll try to reproduce your situation of 2 pinned, 3 regular tabs today and see if I can somehow mimic the "missing tabs" issue you're having. My suspicion is if that wasn't happening, you would then be seeing the correct tab order synchronization that went into this new version.
I too wish there was some way to just hide Chrome's own tab bar altogether :)
---
If you have any more information about what steps you took that resulted in the missing tab issue or suspicions please let me know. That is a show-stopper bug and though I can't seem to reproduce it here I'm very concerned about others running into it!
Sorry to hear the new version isn't working well for you. Unfortunately I haven't encountered the missing-tab problem you describe so I'm at a bit of a loss to help as of yet. One thing that may help is to just reload the extension -- I have a suspicion that that will restore those missing tabs to the tree and it should behave properly after that (hopefully).
As you say, Sidewise should control Chrome's tab order: that is the main new feature of the new version. Unfortunately it sounds like it isn't working right for you, but the intention was that the tab order should stay perfectly in sync between Chrome's tab bar horizontally and Sidewise's tree vertically. Currently Sidewise is set up to respect Chrome's tab ordering initially, and then if you move stuff around in the tree, reorder Chrome's tabbar accordingly (and vice versa).
I'll try to reproduce your situation of 2 pinned, 3 regular tabs today and see if I can somehow mimic the "missing tabs" issue you're having. My suspicion is if that wasn't happening, you would then be seeing the correct tab order synchronization that went into this new version.
I too wish there was some way to just hide Chrome's own tab bar altogether :)
My new plan for addressing this request is to allow the user to reorder/toggle the context menu items from the options page. This will be valuable not only for requests such as yours, but also to keep things manageable as the number of context menu actions grows, some of which may only be desirable to a small subset of Sidewise users.
Once that and the Recently Closed sidebar pane are in place, I will decide whether to move the Close item nearer to the top by default as you suggest.
My new plan for addressing this request is to allow the user to reorder/toggle the context menu items from the options page. This will be valuable not only for requests such as yours, but also to keep things manageable as the number of context menu actions grows, some of which may only be desirable to a small subset of Sidewise users.
-- Marking this as COMPLETED to get it off the todo list :)
Thanks! Look in the coming weeks and months for more unique features, such as a tree-aware Recently Closed sidebar pane, and a Tree Style Histories sidebar pane that will show a given tab's back/forward history as a tree (no more losing history if you go back and then forward to a different URL).
This should be pretty much fixed in the new 2012.10.18.1 release.
Sidewise now checks for and and removes zero-child window rows in cases where Chrome doesn't fire its usual onWindowRemoved event -- as is seemingly often the case with incognito windows.
Please let me know if you're still seeing this problem after updating.
After much experimentation based on your suggestion, I have improved how smart focus works in the new 2012.10.18.1 release. Please see the smart focus option and its subordinate options for the full details, but long story short - smart focus now does just as you suggest in the case you've described.
Also (pertinent to your screenshot), Sidewise will no longer use its smart-focus logic if you close a tab other than the currently focused tab; it just keeps the already-focused tab focused.
The "create new tab" button is now implemented in 2012.10.18.1 release.
Setting this issue to STARTED as I have not yet addressed the issue of restoring previous windows' positions.
Сервис поддержки клиентов работает на платформе UserEcho
My solution should also make Sidewise's startup process (associating open tabs to existing/saved tabs in the tree) much faster in general, which should improve the overall probability of Sidewise placing tabs in the tree accurately on the basis of their tab order (as seen in the Chrome tab bar).