[Ext] Tab Kit 0.5.7 (2009-07-06)

Announce and Discuss the Latest Theme and Extension Releases.
Post Reply
User avatar
Jomel
Posts: 133
Joined: September 30th, 2004, 1:10 pm
Contact:

[Ext] Tab Kit 0.5.7 (2009-07-06)

Post by Jomel »

Tab grouping, multi-rows, tree view, and various tweaks for power users.

Tab Kit makes tabs more efficient for power users, allowing a wide variety of tweaks, all of which are optional, notably:
  • Group tabs, by domain or opener (parent) tab, manually or automatically
  • Vertical tab tree (with splitter), like Tree Style Tab
  • Multi-row tabs
  • Sort tabs, by address, last loaded, last viewed, order of creation, origin or title
  • Control new tab position and close order
  • Easily duplicate tabs/groups and copy/move them between windows by dragging
  • Scrollwheel tab switch
  • 'Mouse rocker' to go back/forward in history
  • Highlight unread tabs (and emphasise current tab)
  • Scrollbar instead of scroll arrows in over-long Bookmarks and All Tabs popups
  • Open Selected Links feature
  • Switch tabs on hover
  • Options for urls, searches and/or bookmarks to open in new tabs by default
For a more comprehensive feature list, visit: http://code.google.com/p/tabkit/wiki/About

Read a review of Tab Kit at CyberNet, including a cool video demonstrating tab grouping, the tab tree, collapsing groups and multi-row tabs.

Screenshots (click for larger images and captions)
Image Image Image Image

Download it at https://addons.mozilla.org/en-US/firefox/addons/versions/5447.

Support

I write Tab Kit for free in my own time, so while I read all feedback please excuse me for not being able to reply personally to every message - my time is better spent improving Tab Kit.

Last edited by Jomel on July 18th, 2009, 7:35 pm, edited 15 times in total.
Creator of:
- Tab Kit: Tab grouping, multi-rows, tree view, and various tweaks for power users
- Tabs Open Relative: Tabs open right of current
- Too Many Tabs!
- Crash Recovery Lite
bob4mary
Posts: 59
Joined: March 25th, 2007, 5:45 pm

Post by bob4mary »

I have been looking for something like this for ages.

I really like the tabs down the left, there are a few things that I would like to see added if possible:
Option to always show the tab bar when it is down the side (separate to the Firefox setting of always show tab bar)
Ability to turn off the colour grouping, the indent is enough for me.
Make the close button show on tabs when they are down the side, also truncate tabs to the width of the side panel.

Thanks
User avatar
Jomel
Posts: 133
Joined: September 30th, 2004, 1:10 pm
Contact:

Post by Jomel »

bob4mary wrote:Option to always show the tab bar when it is down the side (separate to the Firefox setting of always show tab bar)

Hmm, I don't want to add too many prefs as there are already a lot, and it seems the existing always show tab bar pref can cover this well enough...

bob4mary wrote:Ability to turn off the colour grouping, the indent is enough for me.

I can add this if you want, but are you sure the indent is enough? For example on the tree screenshot, the first (green) group only has its second tab indented (because the third one isn't a child of either of the first two), while the light blue group only has the last two tabs indented, because the first three are all siblings. In both cases, it seems that the colouring is very necessary to actually tell where the group is.

bob4mary wrote:Make the close button show on tabs when they are down the side, also truncate tabs to the width of the side panel.

Ah, this used to work but I broke it when adding the splitter. Will fix those.
Creator of:
- Tab Kit: Tab grouping, multi-rows, tree view, and various tweaks for power users
- Tabs Open Relative: Tabs open right of current
- Too Many Tabs!
- Crash Recovery Lite
bob4mary
Posts: 59
Joined: March 25th, 2007, 5:45 pm

Post by bob4mary »

bob4mary wrote:Option to always show the tab bar when it is down the side (separate to the Firefox setting of always show tab bar)

Jomel wrote:Hmm, I don't want to add too many prefs as there are already a lot, and it seems the existing always show tab bar pref can cover this well enough...

Ok, it is your extension, also I hope to be able to use this long term instead of normal tabs so should not be a long term problem for me.

bob4mary wrote:Ability to turn off the colour grouping, the indent is enough for me.

Jomel wrote:I can add this if you want, but are you sure the indent is enough? For example on the tree screenshot, the first (green) group only has its second tab indented (because the third one isn't a child of either of the first two), while the light blue group only has the last two tabs indented, because the first three are all siblings. In both cases, it seems that the colouring is very necessary to actually tell where the group is.

Good point. I was only looking at the children as being part of the group. This could be asking too much but how about making it more tree like? If you had little +/- things then it would be easier to determine if a group was collapsed or not.

bob4mary wrote:Make the close button show on tabs when they are down the side, also truncate tabs to the width of the side panel.

Jomel wrote:Ah, this used to work but I broke it when adding the splitter. Will fix those.

Excellent
********
Posts: 947
Joined: August 24th, 2005, 12:23 pm

Post by ******** »

wow. nice job, jomel. this is the type of thing i tried to achieve with my extension superT and by writing scripts with zeniko's userChrome.js, but when Firefox 2 came and its updated tab browsing API broke superT, i moved on to other things.

one thing i'm curious of is how you managed to get the mouse rocker and tab scrolling to work without causing the contextmenu to popup.
here's the code that i wrote a long time ago to attempt to do this:
http://www.angelfire.com/crazy/zzzaplig ... ures.uc.js
User avatar
Jomel
Posts: 133
Joined: September 30th, 2004, 1:10 pm
Contact:

Post by Jomel »

bob4mary wrote:This could be asking too much but how about making it more tree like? If you had little +/- things then it would be easier to determine if a group was collapsed or not.

Actually, adding a plus button to collapsed-group tabs is already on my todo list, though not particularly high up. Incidentally I don't really think it's worth letting people collapse indented 'subgroups', since groups are rarely enormous and it makes things more difficult to understand (especially if they don't have the tab bar in tree mode).

desertfox wrote:one thing i'm curious of is how you managed to get the mouse rocker and tab scrolling to work without causing the contextmenu to popup.

Glad you like it! :) When I need to prevent the context menu, I set a variable, then in a listener for the "contextmenu" event on gBrowser, if that variable is true I do event.preventDefault() and event.stopPropagation() (it might not need both, but does no harm) and reset the variable. The whole mouse gestures bit could easily just be a userChrome.js snippet, but it was too small and nice not to include!
Creator of:
- Tab Kit: Tab grouping, multi-rows, tree view, and various tweaks for power users
- Tabs Open Relative: Tabs open right of current
- Too Many Tabs!
- Crash Recovery Lite
Old Makondo
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by Old Makondo »

Very nice ext. even though i can't use it 'cause i use TMP. Still, really nice, congrats!
093236
Posts: 172
Joined: May 24th, 2005, 3:21 am

Post by 093236 »

It's a very good ext! I love it so much especially the group tabs!
However, can anyone confirm it?
It makes "the links that will open in new tab/new window" only open in new window.

I am using the trunk build.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080405 Minefield/3.0a8pre ID:2007080405
User avatar
Jomel
Posts: 133
Joined: September 30th, 2004, 1:10 pm
Contact:

Post by Jomel »

@makondo: Sure, it may never be compatible with Tab Mix Plus as they overlap considerably. Though I'd argue that together Tab Kit, Session Manager, and LastTab include most of TMP's useful features.

@093236: Ah - it's currently meant for Firefox 2 only, so some things won't work with trunk builds. I plan to update it for trunk/Fx 3 before too long, it shouldn't be difficult as there have been very few tabbed browsing changes. What exactly do you mean by links that will open in new tab/new window though? Could you give an example page so I can test it?
Creator of:
- Tab Kit: Tab grouping, multi-rows, tree view, and various tweaks for power users
- Tabs Open Relative: Tabs open right of current
- Too Many Tabs!
- Crash Recovery Lite
093236
Posts: 172
Joined: May 24th, 2005, 3:21 am

Post by 093236 »

Thank you, Jomel.
The example is your signature.
When I left click the link of "Tab Kit" or "Tabs Open Relative", it only opens in a new window. But I have set "New pages should be opened in a new tab" in the Options under the Tools menu.
pepo.k
Posts: 14
Joined: July 30th, 2007, 6:05 am
Contact:

tab bar after restart of firefox always "at the top&quo

Post by pepo.k »

Hi Jomel!

I would like to ask u, what I am doing wrong.
I have set the position "at the bottom" in the otions menu of TABKIT. BUT when I start the firefox again, the tabbar is always at the top. I did a control in the setup of TABKIT, and there is ist set "at he bottom", as I set up before restart.
In the about:config was the position set as "3".
I must set it every time after each start of FIREFOX. I must set it at the another position then OK, and then back to the "at the bottom" and OK. Really annoying!
FYI: My other extensions are: adblock + filter uploader, allinonegestures, autohidestatusbar,downloadstatusber,Firesomething,Flashblock,Forecast enh.,Hidemenubar,hidetabbar,IEtab,minimizetotray,Tidymeebo.

Thank for your advice

Kind regards

Pepo
Zalusithix
Posts: 2
Joined: August 7th, 2007, 10:44 am

Post by Zalusithix »

First off, I'd like to express my thanks to you Jomel - I can finally move from Firefox 1.5 to 2.0 now that I can have tab tree functionality once again! To me, any upgrade to Firefox is absolutely meaningless without a tab tree. My starting session contains over 20 tabs and can easily grow to over 100 tabs at peak usage. Attempting that level of tab usage without tree organization of tabs is nigh near impossible.

Now, there's a few things I'd like to suggest for making this extension better. First off, and probably the simplest to implement, would be a way to manually choose grouping colors from a context menu. The auto color generation can run into situations where it makes two adjacent tab groups extremely similar in color, and thus defeats the purpose of group coloring: easy recognition.

The next issue is actually a pair of related issues, and a bit more complex in that they involve the moving of tabs within trees. As it stands, when a tab is dragged into a group that the tab is not normally part of, it becomes part of that group color wise - which makes perfect sense in normal tab bar operation. In tree mode, however, the tab has no logical method of becoming part of the tree. Not only will it not place itself into the correct branch to which it's dragged, but it will in fact destroy that branching part of the tree where it is added (though the section repairs itself if the offending tab is removed). This effect can also be seen while trying to drag tabs within a tree to a different area of that tree. Similarly, dragging the root of any tree or sub-tree fails to pull the associated branches with it. Instead the root moves by itself leaving the rest of the tree structure grouped oddly. Once again, this logic would make sense in bar tab mode, but tree mode requires a different set of logic to work optimally. These limitations prevent any real reorganizing of existing tabs.

My final issue, and a more minor one at that, is that there's no way to close individual sub trees. This is somewhat tied to bob4mary's request for collapsing any given level of the tree. Right now we can close individual tabs, or the entire group, but not any subsections of that group. Pretty much an all or nothing affair. After long browsing sessions I can end up with subsections of trees that I no longer need, and the ability to close out any section would be nice. But this is really tied with bob4mary's request as if one is implemented, it would only make sense that the other would be as well. Alternately if the extension worked with Multiple Tab Handler, closing out any selection of tabs would be easy, but from my experience this extension clashes with MTH.

IMO addressing these issues will go a long way to improving the functionality of this extension. Having a way to manually override the default color allows the user to correct similar colors without having to destroy and recreate the entire tab group. Likewise, improving the tab dragging logic will allow the user to restructure tree groups on the fly without having to destroy and recreate the tabs in different places. Implementing subgroup closing, while less important, nevertheless saves the user a bit of time if they're closing numerous tabs, and is the logical compliment to subgroup collapsing.

And as for existing features, is it just me not figuring it out, or is the "create new group from consecutive tabs" option broken? It just locks the cursor to a different type for me and freezes the context menu options to whatever the last options were when I selected the option. I haven't figured out how to return to the normal operation outside of restarting Firefox.

Once again, I truly thank you for starting this extension, and I don't want this reply to come off as a complaint on the current functionality. I understand its in beta and there's bound to be problems and changes ahead. I just wanted to throw the ideas out there so that this extension can become as integral as TBE was to a lot of us wide-screen monitor users!
User avatar
Jomel
Posts: 133
Joined: September 30th, 2004, 1:10 pm
Contact:

Post by Jomel »

Firstly I've released a new version fixing one or two things that were pointed out. Changelog:
  • Close buttons now show on tabs (if enabled) when the tab bar is vertical, and tab text is cropped appropriately. (pointed out by bob4mary)
  • Vertical or multi-row tab bar will now autoscroll to make sure new (background) tabs are onscreen
  • Fix: Tab bar and sidebar positions are now remembered even if they are on the bottom and right respectively (as pointed out by pepo.k)
  • Fix: Context menu searches are now correctly grouped

Now for a few replies:

093236 wrote:The example is your signature.
Thanks, I'll look into it.


pepo.k wrote:I have set the position "at the bottom" in the otions menu of TABKIT. BUT when I start the firefox again, the tabbar is always at the top.
Oops, I'd made a typo. I've fixed it in the version I just
released - thanks for pointing it out!


Zalusithix wrote:First off, and probably the simplest to implement, would be a way to manually choose grouping colors from a context menu. The auto color generation can run into situations where it makes two adjacent tab groups extremely similar in color, and thus defeats the purpose of group coloring: easy recognition.
I've noticed this problem too. Manually choosing colours might get a bit tedious however. I was planning to tackle this by automatically checking that the colours allocated were distinct from those of neighbouring groups - would this be sufficient for you? (I accept that it might still be possible, by closing groups, to get two neighbouring groups of similar colour, but this would be much rarer). In the meantime a workaround is to rightclick one of the end tabs of the group, choose Create New Group From Consecutive Tabs, then click the tab at the other end of the group and accept the prompt - this should generate a new colour for the group.

Zalusithix wrote:The next issue is actually a pair of related issues, and a bit more complex in that they involve the moving of tabs within trees. As it stands, when a tab is dragged into a group that the tab is not normally part of, it becomes part of that group color wise - which makes perfect sense in normal tab bar operation. In tree mode, however, the tab has no logical method of becoming part of the tree. Not only will it not place itself into the correct branch to which it's dragged, but it will in fact destroy that branching part of the tree where it is added (though the section repairs itself if the offending tab is removed). This effect can
also be seen while trying to drag tabs within a tree to a different area of that tree.
Oh dear - this is where things start to get complicated ;)
The way it currently works is that each tab remembers its "parent tab" (often just the current tab when it was opened), and when calculating the indents, if the above tab is its parent it increases the indent, if it's a sibling it keeps the indent the same, otherwise it decreases the indent. Hence as you've noticed, dragging a tab in between a parent and its children hides the parent from them, and they lose an indent level, which I admit is rather counter-intuitive. I can probably fix this by making dragged tabs copy the parent tab of the tab after them though.

Zalusithix wrote:Similarly, dragging the root of any tree or sub-tree fails to pull the associated branches with it. Instead the root moves by itself leaving the rest of the tree structure grouped oddly. Once again,
this logic would make sense in bar tab mode, but tree mode requires a different set of logic to work optimally. These limitations prevent any real reorganizing of existing tabs.
I'm still undecided as to what you should be able to do to subtrees. However for dragging the root that's already possible: Hold down Shift while you drag any tab from a group, and instead of moving that tab, you'll move the whole group in one go. Note that you can even drag a group into another group to merge them, but this is a little clumsy since you really must drag it within the other group, when it would often make more sense to keep the tabs from each group separate.

Zalusithix wrote:there's no way to close individual sub trees. This is somewhat tied to bob4mary's request for collapsing any given level of the tree. Right now we can close individual tabs, or the entire group, but not
any subsections of that group. Pretty much an all or nothing affair. After long browsing sessions I can end up with subsections of trees that I no longer need, and the ability to close out any section would be nice. But
this is really tied with bob4mary's request as if one is implemented, it would only make sense that the other would be as well. Alternately if the extension worked with Multiple Tab Handler, closing out any selection of
tabs would be easy, but from my experience this extension clashes with MTH.
Wow, you must use even more tabs than me ^_^. I'm slightly reluctant to add subtree behaviours since even with the tab bar vertical the indent is optional, and I think it would be clearer if all modes worked the same. I could add something similar to Multiple Tab Handler though, it would be quite useful for creating groups too (Create New Group From Consecutive Tabs is clunky, even when it does work). I don't think it's worth replacing the default drag behaviour like MTH does (by default), but I could for example provide Shift-click to select all tabs from the current tab to the clicked tab, and Ctrl-click to toggle selection of tabs.


Zalusithix wrote:is the "create new group from consecutive tabs" option broken? It just locks the cursor to a different type for me and freezes the context menu options to whatever the last options were when I selected the option. I haven't figured out how to return to the normal operation outside of restarting Firefox.
I've actually noticed this too - it works on one of my computers but not the other! I'll fix it as soon as I understand what's going on :-k

Zalusithix wrote:I don't want this reply to come off as a complaint on the current functionality. I understand its in beta and there's bound to be problems and changes ahead.
No not at all, this is really useful feedback; I can't thank you enough!
Creator of:
- Tab Kit: Tab grouping, multi-rows, tree view, and various tweaks for power users
- Tabs Open Relative: Tabs open right of current
- Too Many Tabs!
- Crash Recovery Lite
Zalusithix
Posts: 2
Joined: August 7th, 2007, 10:44 am

Post by Zalusithix »

Jomel wrote:I've noticed this problem too. Manually choosing colours might get a bit tedious however. I was planning to tackle this by automatically checking that the colours allocated were distinct from those of neighbouring groups - would this be sufficient for you? (I accept that it might still be possible, by closing groups, to get two neighbouring groups of similar colour, but this would be much rarer). In the meantime a workaround is to rightclick one of the end tabs of the group, choose Create New Group From Consecutive Tabs, then click the tab at the other end of the group and accept the prompt - this should generate a new colour for the group.
I definitely think an automated checking algorithm is a great idea. I don't see why this has to be exclusive to a manual override option though (not a replacement for automated color generation which is what I think you interpreted my suggestion as). A manual override would solve the group closing problem you brought up by allowing the user to specify a replacement color. It also allows the user to replace a color that they dislike (such as an aversion to hot pink or some such). Alternately, if the objective is trying to avoid as much code bloating as possible, then adding an option to force run the color picker algorithm again for the selected group via the context menu is probably the simplest effective idea. If the algorithm takes into account both the preceding and the following group colors, it would provide a fix to the similarity possibilities that arise on group closings, and also would provide a way for the user to discard a color choice they don't prefer (albeit in a rather slot machine manner).

Jomel wrote:he way it currently works is that each tab remembers its "parent tab" (often just the current tab when it was opened), and when calculating the indents, if the above tab is its parent it increases the indent, if it's a sibling it keeps the indent the same, otherwise it decreases the indent. Hence as you've noticed, dragging a tab in between a parent and its children hides the parent from them, and they lose an indent level, which I admit is rather counter-intuitive. I can probably fix this by making dragged tabs copy the parent tab of the tab after them though.
That solution is probably the best bet while using the current mechanics. The algorithm should make sure that only first level tabs have their parent re-designated though so as to preserve the structure of a dragged tree.

Jomel wrote:I'm still undecided as to what you should be able to do to subtrees. However for dragging the root that's already possible: Hold down Shift while you drag any tab from a group, and instead of moving that tab, you'll move the whole group in one go. Note that you can even drag a group into another group to merge them, but this is a little clumsy since you really must drag it within the other group, when it would often make more sense to keep the tabs from each group separate.
Personally I think that the user should have organizational control of sub trees. Using the same logic as mentioned above on resetting the parent along with the shift+drag method, it would allow the user to reorganize the sub trees while keeping everything structured correctly. (This is assuming shift+drag simply collects the current tab and all children for moving) At the same time it shouldn't really mess with tab-bar mode or non-indented vertical tab mode people as they wouldn't be holding shift while moving arbitrary tabs. And as for the clumsiness you mention on group merging, the only way I can think of to avoid that is to have another shift+drag type movement registered like alt+drag. In that mode it appends the current tab and all children of it to group ahead of the drop location by resetting the parents of the dragged tabs to the root of the group ahead.

Jomel wrote:I'm slightly reluctant to add subtree behaviours since even with the tab bar vertical the indent is optional, and I think it would be clearer if all modes worked the same. I could add something similar to Multiple Tab Handler though, it would be quite useful for creating groups too (Create New Group From Consecutive Tabs is clunky, even when it does work). I don't think it's worth replacing the default drag behaviour like MTH does (by default), but I could for example provide Shift-click to select all tabs from the current tab to the clicked tab, and Ctrl-click to toggle selection of tabs.
I see where you're coming from with keeping all modes working the same. I'm just obviously partial to tree mode. ;) I can live without sub-tree collapsing though. As for implementing a MTH sort of method on selecting tabs, that seems like a great idea. I agree that it shouldn't replace the default drag option by default, but to have an ability to easily select arbitrary groups of tabs is quite useful for a number of reasons - some of which you've pointed out.

Jomel wrote:I've actually noticed this too - it works on one of my computers but not the other! I'll fix it as soon as I understand what's going on
Odd, but ultimately a minor issue if the method gets replaced with a selection mechanism like described above. =)

Finally, thanks for the new version! While the changes are mostly minor, working close buttons and text cropping go a long way towards making things look more polished.
bob4mary
Posts: 59
Joined: March 25th, 2007, 5:45 pm

Post by bob4mary »

Is there any possibility of making the big white space under the tabs (when they are left or right) be the same as the colour behind the tabs when they are across the top or bottom? I find the contrast with most web sites distracting and this would be the only thing stopping me from using this extension in the long term.

Now for the really picky one, how about a bevel on the top edges (or maybe just one corner) of the tabs when they are on the left or right?
Post Reply