Good idea, marking as PLANNED. 

I like this new-tab-button idea. Setting as PLANNED.

I will investigate what would be involved in restoring previous windows' positions on restart. It does seem like something Chrome should be doing itself (and from what you are saying it must not be); I think it may be possible for Sidewise to remember each Window's positions and reapply them once it recognizes which window is which on browser restart.

I like this idea. Setting as PLANNED.

I will investigate what would be involved in restoring previous windows' positions on restart. It does seem like something Chrome should be doing itself (and from what you are saying it must not be); I think it may be possible for Sidewise to remember each Window's positions and reapply them once it recognizes which window is which on browser restart.

This does sound like a Chromium or Linux-specific bug. On my Windows Server 2008R2 / Chrome 21.0.1180.79 m setup, I can do Ctrl+Shift+N, Ctrl+W and the incognito window entry in the tree immediately disappears as one would expect.

What about this solution?: after onTabRemoved, check if the containing window node now has zero children, and remove it if so. I *think* this would yield the correct result if onWindowRemoved fails to fire, though I'll need to make sure this doesn't do anything nasty when onWindowRemoved actually does fire properly.

I'll give some thought to your idea of adding a "force reindex" ability. I am currently working on getting tab-index-ordering working everywhere, so that the Chrome tabbar always presents tabs horizontally in the same order as they appear in the tree vertically. I'll probably be implementing something akin to a "complete reindex" function in this process, e.g. to properly initialize the tree+tabbar when the extension is first installed.

The "reset tree" function available at the bottom of the sidebar in debug mode works a bit like "force reindex" already, but it is a little too hardcore for normal use since it blows away the entire existing tree (all folders & hibernated rows are lost).

I like it!

Do you like it if you leave color:gray in too? I've got two monitors here which reproduce colors a bit differently, and on one of my monitors hsl(0,0,95%) is barely visible ;) Using all three CSS rules makes these rows visibly distinct on both of my monitors. I am currently thinking of just making the 3-rules be the default hibernated style.

My long term plan is to implement some sort of theming system, which will probably end up just being an ability to switch between different CSS files. For the shorter term though, I am considering just adding a "custom CSS rules" box on the options page, which would at least give some custom styling ability to those who want to get their hands dirty.

Yeah I agree. At least on my two monitors, gray/95% is distinguishable on both while not 'blending in' too much with the background.

Think I'll go with this for the next release.

Definitely a bug and not working as intended. Marking as a planned fix for the near future.

Oh that's interesting. On Windows, a single click on a row in the sidebar both activates the sidebar and sends that click through to do row-focus as well.

Marking this as planned -- should not be hard at all to implement "focus row on mouse hover" as an option.

I like it!

Do you like it if you leave color:gray in too? I've got two monitors here which reproduce colors a bit differently, and on one of my monitors hsl(0,0,95%) is barely visible ;) Using all three CSS rules makes these rows visibly distinct on both of my monitors. I am currently thinking of just making the 3-rules be the default hibernated style.

My long term plan is to implement some sort of theming system, which will probably end up just being an ability to switch between different CSS files. For the shorter term though, I am considering just adding a "custom CSS rules" box on the options page, which would at least give some custom styling ability to those who want to get their hands dirty.

It is technically possible to have the tabbar appear inside pages, but unfortunately it's not possible for every type of page (e.g. not on chrome://* pages, http://*.png, ftp://*, ...); and that is the main reason I didn't take that approach. That and the fact that it would take significantly more resources to draw/maintain a tabbar within every open tab.

The real proper fix for the issue you describe is for the Chrome team to implement a true sidebar API for extensions to use. They had one mostly working in 2011, but decided to cancel the whole project and delay the implementation until 2013 soonest. Given that, I decided a "best approximation" solution would have to suffice until then.

Assuming you're on Windows, a possible partial solution for the resizing issue is just to maximize the docked-to window whenever you want the maximized effect. I agree it's not pretty having two windows open, but at least you can get a decent approximation of a true maximized-window-with-sidebar that way. For what it's worth, it took me a couple weeks to get used to the "not really maximized" look, I don't notice it anymore.

If you have multiple monitors you might also try turning off the "allow Sidewise to unmaximize the dock window" option and see if that suits you.

I like the black/theming idea, and am marking this issue as "planned" until I get to implementing a proper theming system. It's all just CSS driven styling so it should be pretty easy for myself and others to produce new themes.