Your comments

Can you be more specific? It sounds like you are saying that Sidewise isn't tracking what happens to Chrome's tabs in any way. Is that the case, or is something specific being missed by Sidewise?

Thanks flynn for posting the appropriate fix of updating your Chrome to the current released version.


I did not see this bug report until today; apologies for the late response.

It looks like there is a way to specify "minimum Chrome version" for the extension which I was not aware of. I'll be sure to set that appropriately for future releases.

Thank you all for your patience and positive support. It has definitely taken me too long to get this open sourced.


I need to fix the build script which is currently heavily dependent on several arcane Windows-only tools, then it should be in sufficient shape to post up on Github. Once posted I will continue to address several much needed code fixes in the public repo, where others can also contribute fixes and improvements or repurpose the code for their own needs.

Uncheck 'enable diagnostics' in the options page.

Good idea. Adding to the todo list; I am concocting a "custom theme/CSS" set of options for Sidewise and this sounds like a good fit.

If this were done, do you think you would want the icons to scale up in size (and pixelate) too?

Good idea. Adding to the todo list; I am concocting a "custom theme/CSS" set of options for Sidewise and this sounds like a good fit.

Actually, Chrome doesn't let us set alwaysOnTop for windows; that is a readonly properly. The solution is basically to focus() the main Chrome window then [re]focus() the Sidewise window.


Or vice versa: when the main Chrome window gets focused, we focus() the sidebar and then refocus() the main Chrome window so that the window the user focused will be the one focused after the "raise" is done. If this is not done, then whenever the main Chrome window is focused, we would (raise and) switch focus to the sidebar -- leaving the main Chrome window unfocused.


What if I added an option to prevent that second refocus()? So when the main Chrome window gets focused by the user (while a non-Chrome app has the focus), we would focus() the sidebar, but leave the focus there. If the user actually wants the main Chrome window focused, then they would have to manually click it (and since a Chrome window already is focused here, we would not do any more automatic focus()ing).


Then it would take two clicks (or with XMouse, a main-window hover followed by a sidebar-hover followed by a hover back to the main window) to get the main window focused.


Do you think that would be useful?

As you have probably gathered, this whole scenario is a total hack, and the addition of a raise() function in Chrome would eliminate almost all of this workaround code.


Another option to consider is turning off your "keep sidebar visible" option and setting the "when browser button is clicked" option to "dock sidebar to window". Then you don't get sidebar auto-raising, but you can still do it manually by clicking the Sidewise button next to the address bar.


Lastly, I'll mention that I used to be an XMouse user, but for me I have found something better which I will call XScroll. All this does is send mousewheel events to the window that the pointer is over rather than the focused window; mousing over a window doesn't raise it. It's not quite as nice as the full XMouse functionality (i.e. being able to type to a non-top window), but the scrolling aspect is the part I used most wrt XMouse, and the XScroll strategy avoids a lot of the potential downsides and quirks of what XMouse does in certain applications. Let me know if you're interested.

Thanks for this :) Incidentally, that is the primary reason why I ended up creating Sidewise -- I really wanted to use Chrome but having 100 little triangular wedges along the top of the window just wasn't cutting it!

I'm putting this on the todo list after a couple high priority bugs.

For now, I'm thinking of implementing this as part of a "custom style/CSS" feature which basically lets the user enter any custom CSS they want to restyle the sidebar. And I will include a small handful of default style schemes with that such as "black on white mode".

I think I can probably accomplish at least half of what you want using this strategy by including a "super narrow mode" that basically gets rid of everything to the left of the page-icons in the sidebar.

It would be a bit trickier to disable tree functionality since so much of the sidebar's operation assumes a tree (e.g. how drag and drop works). So I will probably punt on that aspect for now.

But it shouldn't be too hard, at least cosmetically, to hide all left-indentation and dropdown arrows. If you take a look at the 'Recently closed' sidebar pane, you can already see some semblance of this: the icons are all the way to the left, and if you hover one of the icons for a page that has children, you get the usual drop-down arrow exposed. Mimicking this style on the Pages pane should get us pretty close.