Add an option to put the tabs on the right instead of the left.

bwinton commented 8 years ago

Just for @deadsquid. 😉

pdehaan commented 8 years ago

@bwinton Is this done? It seems to be mostly working with the "Display tabs on the right" preference.

Ref: https://github.com/bwinton/VerticalTabs/issues/38

bwinton commented 8 years ago

No. That was the old code, which didn't work with the new layout, which was only implemented in light theme. :wink: I've removed the previous non-working implementation, so we should keep this open to track the work in the future, if we decide it's worth doing.

donlencho commented 8 years ago

I would prefer it on the right and would appreciate if there was a choice. Thank you,

kuoe0 commented 8 years ago

I also prefer to put it on right!

PenTagaris commented 8 years ago

+1 to this. I don't have any idea where to start, but if there are any pieces of example code floating around, I would be happy to contribute, as well!

bwinton commented 8 years ago

@jstnchristian: So, there are a couple of different places to change…

First, you should add the option to this file so that the user can change it.

Then, in verticaltabs.jsm, add some code to read the value of the preference, and set an attribute on the document.

Finally, in skin\base.css, add some rules that look for #main-window[sidebaronright], and force the sidebar (and the splitter, and a bunch of other stuff) to be on the right. 🙂

Let me know if you try this and run into any problems, and I'll do my best to help.

april commented 8 years ago

Definitely gets my vote as the best issue. It's the only thing that's keeping me on Tree Style Tabs! :)

Mentis commented 8 years ago

Would definitely switch from TreeStyleTabs when this will be resolved. TabCenter is much more stable and usable.

fflorent commented 7 years ago

I also prefer placing the tabs on the right for a simple reason: some pages offer action buttons on the far left of the page, like ehterpad as above: selection_037

As you can see, the bold button (in blue) is right beside to the tabs (in green) and that's quite frustrating when you hit the tab :).

So yeah, IMHO the best option would be to place the tabs on the right by default (as action buttons are rarer on the right), as the Vivaldi Browser does.

Florent

edwardgalligan commented 7 years ago

Just a small followup to the above comments on the usability of Tab Centre in general:

Close buttons are on the right of tabs, the furthest point on the tab from screen-edge, which makes it far harder to hit them easily + quickly (Fitts' Law). Moving tabs to the right would (should) solve this (though perhaps always having the close buttons on the "outside" would be a good idea anyway)
Close buttons are completely hidden when the bar is in collapsed mode, making closing tabs a tricky two-move mouse operation. Again solveable by moving to the right and/or always having it on the "outside"
Back/Forward buttons shift position between modes (collapsed/expanded) - if the bar were on the right, the settings button/addons buttons would move, but I figure back is a more oft-used button.

Generally, I'd very much be with @fflorent on right being the default.

bwinton commented 7 years ago

Close buttons are on the right of tabs, the furthest point on the tab from screen-edge, which makes it far harder to hit them easily + quickly (Fitts' Law).

Yes. This is on purpose, because in previous rounds of user testing people were accidentally closing tabs when trying to switch to them. If we did add an option for having the sidebar on the right, we would need to test a few different options for where to put the close buttons to see which one causes the least frustration.

For people who are concerned about the speed of closing tabs, we recommend using ctrl-w (or cmd-w on Mac) to close tabs, since that will be much faster. 🙂

edwardgalligan commented 7 years ago

On ctrl-w/cmd-w, UI UX (button placement) is a very separate topic to keyboard shortcuts. I usually ctrl-w, but the mouse and keyboard are separate peripherals. When I'm using the mouse, switching to keyboard for specific functionality is pretty suboptimal.

That said, point taken on accidental closing. As a long time user of right-hand tabs on other browsers with close buttons on the outside, I've never encountered this as an issue, but I'm sure my experience doesn't reflect everyone's. Tricky compromise.

ShalokShalom commented 7 years ago

+1

mgoerlich-dev commented 7 years ago

Please implement this. Having it on the left feals totaly unnatural for me, especially considering that for a while now the whole application style moved to a UX thats more focused on the right side. Like all Add-On Buttons and the Hamburger menu on the right side, only thing on the left are the navigation buttons which i rarely use. Also, I start reading at the left and it would "feel better" if didn't have to skip over the Tab Center everytime if you get what I mean.

TL;DR: I work with my right hand, I read from left to right, it would be more natural (for me) to have all the content on the left and the UI-fuzz on the right…

Until this is implementd I probably'll go back to TreeStyleTabs.

bwinton commented 7 years ago

You should go back to Tree Style Tabs. It's an excellent add-on and I heartily recommend it. Given how long it's been, realistically speaking, we probably aren't going to implement this, and it doesn't look like anyone else is stepping up to fix it either…

mgoerlich-dev commented 7 years ago

Acutally TST is not good permanent solution to my usecase. I don't need all that Tree stuff in there. A simple, auto-shrinking, vertical list of tabs on the right side of my browser window is all I need.

I already tested a few other Vertical Tab AddOns, but none of them felt…as smooth and simple as TabCenter. So, TabCenter would be perfect, except for this issue right here.

I cloned the repo and took a look at the files you mentioned in here, I couldn't find the options.xul, but it seems like the options were moved to the package.json Everything else should still be applicable, am I right? /Edit: Except that verticaltabs.jsm is called verticaltabs.js now…

I'll give it a try, even if don't know 💩 about how Firefox's layouting is working…I want this to work and It can't be that hard.

bwinton commented 7 years ago

Oh yeah, that was a while ago. The options are now in package.json, as you said.

mgoerlich-dev commented 7 years ago

I forked the repo and played around with it for a while now and made some changes.

https://github.com/bwinton/TabCenter/compare/master...MaThGo:f5655c9

These changes introduce the preference option to move the UI to the right side and the neccessary Layout/Style changes to display it on the right.

Things left to do:

Resizing is inversed when the UI is on the right (should be easy to fix)
I couldn't find a way to reposition the splitter without moving it in the dom, is this applicable?
Changing the option, needs a restart (to reposition the splitter)
I broke some things for the left-side display, will fix that
Mark the pref as experimental? (mainly because of potential visual glitches)

Also commits aren't fitting the Contribution Guidlines, but I'll change that before doing a PR. I think next week there will be a PR from me :)

ericawright commented 7 years ago

@MaThGo - awesome, thank you for taking this on! As for commit messages, don't worry about that, those conventions are really only for the merge commits, not each one.

mgoerlich-dev commented 7 years ago

All I'm doing is giving back. :)

Thanks for letting me now about the commit messages.

ericawright commented 7 years ago

@MaThGo I took a look at your branch and did a few quick tests - if you want to make a PR it'll be easier for me to comment.

#main-window[showtabsright] #verticaltabs-box { should have showtabsright=true as the right styling was applied before I got a chance to set the pref and it was very messy.

When clicking on the pref it doesn't automatically change - I needed to toggle it to the top then side again to trigger the change. There's an example of a listener on pref change in verticaltabs.js line 391. I'm not sure why it would require a restart because of the splitter...?

Would probably be good to mirror the icons on the top. I think it's probably a good idea to have the 'x' icons on the inner left side of TC too. And especially the scroll bar when there are many tabs.

The splittter resizing being inverted - very cool bug! to fix it change verticaltabs.js line 670 to let xDelta = document.width - event.screenX (if the pref is set)

There's a bit of styling on the #verticaltabs-box border-right: 1px solid hsla(0, 0%, 0%, 0.2) !important; which could be overridden withborder-left.

It looks really good though, and causes far fewer bugs than I expected!

That being said, we are prepping for a test with TC right now and I'm not sure we want to add a large change like this that could come with a high degree of unpredictability. I'd need to ask @phlsa and @bwinton if this is something we want to commit to supporting. Possibly it could get integrated as a hidden pref at first (kind of like small-tabs) just for the select few who really want it.

mgoerlich-dev commented 7 years ago

#main-window[showtabsright] #verticaltabs-box { should have showtabsright=true as the right styling was applied before I got a chance to set the pref and it was very messy.

Yeah, that was what I meant when i talked about messing up the default UI. Thought it'd be that kind of mistake, but didn't invested time into that now, thanks for catching it. :)

When clicking on the pref it doesn't automatically change - I needed to toggle it to the top then side again to trigger the change. There's an example of a listener on pref change in verticaltabs.js line 391.

Got this on my Todo list, and already found the mentioned listener, still thank you :) Updating the attribute and maybe calling this.rerenderXUL in there should be sufficient, just need to implement it.

I'm not sure why it would require a restart because of the splitter...?

Nevermind, that was just my initial suspicion before i looked further into the code. Like I said I have like zero experience with the XUL-Ecosystem, so I didn't knew how flexible it is. But I have to say, with the help of the Browser Toolbox, it's really easy to get started if you have previous experience with HTML/CSS/JS.

Would probably be good to mirror the icons on the top. I think it's probably a good idea to have the 'x' icons on the inner left side of TC too. And especially the scroll bar when there are many tabs.

Got this as 'urgent' on my todo list, since it's really disruptive if you close the Tab you tried to open. Can even get frustrating at times if it happens to often because your fingers are to fast. 😅

The splittter resizing being inverted - very cool bug! to fix it change verticaltabs.js line 670 to let xDelta = document.width - event.screenX (if the pref is set)

Yeah, that works, but it's still buggy for me, the first time xDelta is always negative which will trigger if (this.pinnedWidth < 30) this.pinnedWidth = 30. After that first hiccup its working fine somehow.

There's a bit of styling on the #verticaltabs-box border-right: 1px solid hsla(0, 0%, 0%, 0.2) !important; which could be overridden withborder-left.

Thanks, I'll change that :)

It looks really good though, and causes far fewer bugs than I expected!

Thank you very much, I also expected it to be more of a hassle. :)

Also thanks for the feedback and the help, it's really appreciated.

That being said, we are prepping for a test with TC right now and I'm not sure we want to add a large change like this that could come with a high degree of unpredictability. I'd need to ask @phlsa and @bwinton if this is something we want to commit to supporting. Possibly it could get integrated as a hidden pref at first (kind of like small-tabs) just for the select few who really want it.

There is no pressure about releasing this in the near future from my side, integrate it how it best fits the projects roadmap or don't do it at all if you decide so. I'll just use my fork until that decision is made and will just keep using it if it wont make it into stable. :)

If you need help with supporting this, I'll probably be using it for a while and will be happy to fix every bug I can find about, in the end it's "my little feature" but I can comprehend that this isn't relevant for the decision. What I can't do is testing it on Windows or Linux I got neither of the systems. All thats implemented for now is untested on these platforms as well.

I've got some spare time over the weekend, but probably won't have access to a internet connection, so I think you can expect the next batch of changes on Sunday evening. That should probably fix everything I currently have on my Todo.

mgoerlich-dev commented 7 years ago

Hey @ericawright, I obviously didn't made it till sunday, sorry for that.

But now, I have actually not a PR for you, but two branches that I'd like to get some thoughts on:

First one being good old right-side you already now, but with additions that should fix everything we spoke of, including a little bug i just discovered when viewing Videos in Fullscreen.

BUT, since I didn't find a way to target the tab-close-buttons with the usual DOM methods (document.getElementsByClassName for example) I just rearranged the Layout for both sides. The buttons in this branch are between the Preview Thumbnail and the Tabtitle regardless which side the tabbar is rendered.

As an alternative, with some flaws that should be fixable, there is inverse-ui-right which solves the tab-close-button problem by marking the whole tabbar as RTL which will mirror it from top to bottom.

Issues:

Probably render bugs on actual RTL UIs
Wen autohide is enabled, the thumbnail somehow drops position, don't know why.
Probably some more bugs

Acutally, thats just a thoughtplay, because I'm not actually statisfied with that first solution, even it's the best choice right now from viewpoint, thinking pragmatic…

I'd really welcome some input from you, maybe you know a way how I can target these .tab-close-button elements in runtime so I can make the first branch more dynamic or a maybe different approach…

ericawright commented 7 years ago

The tab-close-buttons are anonymous XUL elements, so they cannot be selected by the usual methods that you would use for HTML elements. You can find a bit more info in the MDN on modifying XUL elements: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Dynamically_modifying_XUL-based_user_interface#Anonymous_content_.28XBL.29

The way you would select the .tab-close-buttons could be something like this: document.getAnonymousElementByAttribute(tab, "anonid", "close-button") where tab is document.getElementsByClassName('tabbrowser-tab')[0]

That being said, I don't think that selecting that element and moving it around is the most efficient way to do it. If there are many tabs we'd need to grab each of them and shift the button, and every time a new tab is created, again we'd need to shift the button. It looks like what needs to be done is to redefine a new css binding for .tabbrowser-tab and change the <content> portion.

So in override-bindings.css you could add:

#main-window[showtabsright="true"] .tabbrowser-tabs[vertical="true"] .tabbrowser-tab {
  -moz-binding: url("chrome://tabcenter/content/vertical-tabbrowser.xml#tabbrowser-tab-on-right") !important;
}

Then in vertical-tabbrowser.xml add something like:

<binding id="tabbrowser-tab-on-right"
    extends="chrome://tabcenter/content/vertical-tabbrowser.xml#tabbrowser-tab">
    <content>
    ...
    <content/>
<binding/>

Then copy and change/rearrange the <content> starting from line 722 in the same file to redesign the layout of the tabs.

Let me know if you need more clarification on any of that.

agilob commented 7 years ago

bump. is it possible to get this feature anytime soon?

bwinton commented 7 years ago

It doesn't look like anyone has had time to work on it, so no, it's not likely to come anytime soon.

ShalokShalom commented 7 years ago

Seems there is much request on it

agilob commented 7 years ago

The initial idea of putting it on left side seems like misunderstanding to me. Right side of a screen is used less time, and people tend to sit closer to the left side of keyboard due to numeric keyboard being used less often. With current setup I sit closer to left side of keyboard but have to look right where content is, width of numeric keyboard on the screen is taken by tabs. I could just sit and look straight if the tabs were on right side of screen.

mgoerlich-dev commented 7 years ago

I've already done some work on this and basic functionality is already implemented in my fork. But currently I'm to busy so I wont be able to continue work on this for now. Next week I'll have a lot more spare time and I hope that I'll manage to prepare a proper PR for this.

Am 14.04.2017 9:28 vorm. schrieb "agilob" notifications@github.com:

The initial idea of putting it on left side seems like misunderstanding to me. Right side of a screen is used less time, and people tend to sit closer to the left side of keyboard due to numeric keyboard being used less often. With current setup I sit closer to left side of keyboard but have to look right where content is, width of numeric keyboard on the screen is taken by tabs. I could just sit and look straight if the tabs were on right side of screen.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bwinton/TabCenter/issues/7#issuecomment-294107243, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcReWmc5T7b7tudTHG9UDWntO0ayoENks5rvyA1gaJpZM4H4v7t .

eboye commented 7 years ago

Any news on this? I just enabled this tab featured on my 21:9 monitor and it it's awesome ... but I would like to move the tabs to the right as I tend to move my cursor to the top left to go back and that's where the tabs are now. It would be much more intuitive to move those tabs to the right as that's where the "rest" of UI is in my mind.

grahamperrin commented 7 years ago

:+1: to the option.

:-1: to the right-hand-side as the default for sidebars.

… application style moved to a UX thats more focused on the right side. …

That's a weird experience where (without focusing solely on Firefox) UI elements are more generally to the left; or where a desktop environment makes it easier to work with such things on the left.

Jiehong commented 7 years ago

With this bug report filled in Firefox 55, providing the option to move the bar on the right should be easier.

Is the new sidebar api used in TabCenter?

Keith94 commented 7 years ago

@Jiehong It's available in https://addons.mozilla.org/firefox/addon/tab-center-redux/

bwinton / TabCenter

Add an option to put the tabs on the right instead of the left. #7