Aza Raskin [:aza] Reporter
	Description • 14 years ago

* The two buttons do similar things, one at the all-groups level and one at the current group level. These should be combined into a combo button: on the left the Panorama icon and the right a small drop-down arrow.
* The drop-down should now show tabs from all groups, with the current group on top, each group separated by a horizontal separator and named (in standard menu form).

	Esteban Böhmecke [:skele]
	Comment 1 • 14 years ago

What about leaving the button as it is and activate a dropdown menu when you do a long-press on that button? :>

	Aza Raskin [:aza] Reporter
	Comment 2 • 14 years ago

Long-presses are (1) undiscoverable and (2) time-dependent which is rarely good. Would prefer a split button.

Assigned to Shorlander for the visual design of the button.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 4 • 14 years ago

Shorlander/Aza, please take the thoughts on bug 587538 into account as you reconsider the Panorama and list tabs buttons.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 5 • 14 years ago

We need a design here. I agree that we probably want a combobutton approach where the primary action is opening Panorama, and the secondary is to quickly switch between groups.

	ithinc
	Comment 6 • 14 years ago

(In reply to comment #0)
> * The drop-down should now show tabs from all groups, with the current group on
> top, each group separated by a horizontal separator and named (in standard menu
> form).
Maybe make each group a submenu would be better?

	Aza Raskin [:aza] Reporter
	Comment 7 • 14 years ago

Attached a sketch of an idea. Still needs to be made by Horlander for Mac, Windows, and Linux.

	(mostly gone) XtC4UaLL [:xtc4uall]
	Comment 8 • 14 years ago

If you set "browser.allTabs.previews" to "true" you get the "new", but still non-default Tab Preview Button/Function.

Will this be taken into Account?

	Aza Raskin [:aza] Reporter
	Comment 9 • 14 years ago

My understanding was that feature will be going away, but please start another bug for that.

	ithinc
	Comment 10 • 14 years ago

Maybe all groups (without expanding) and all orphans, a separator, and all visible tabs is enough. A hidden preference could be added for whether to expand groups.

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 11 • 14 years ago

vertically align the panorama button and the all tabs drop down.  It is unusual for any control on OS X (with the exception of the traffic light window controls) to have any form of hover state.

	Aza Raskin [:aza] Reporter
	Comment 12 • 14 years ago

The drop-down should list tabs from all tabs in that window. See the attachment for how this looks.

	ithinc
	Comment 13 • 14 years ago

I preferred the following:

Active Tab of Group1 | Group1[n] (show "Group1[n]" as acceltext)
Active Tab of Group2 | [n] (if no group name, show only [n])
Orphan Tab 1
Orphan Tab 2
------------------------------
Tab 1
Tab 2
Tab 3

	ithinc
	Comment 14 • 14 years ago

If a hidden expand or not preference is set, the group items may be expanded as a menu.

	alexander :surkov (:asurkov)
	Comment 16 • 14 years ago

(In reply to comment #15)
> *** Bug 609625 has been marked as a duplicate of this bug. ***

Could the button be placed near of application tabs since application tabs can be used to switch between groups like panorama button. I find annoying to move mouse through whole screen often because apps tabs and panorama buttons are "hot" UI controls.

	Ian Gilman [:iangilman]
	Comment 17 • 14 years ago

Raymond, can you take this on?  It's our only bug that's actually marked as blocking Beta8, so we should take care of it sooner than later (Anant has been doing great work, but his availability is unpredictable).  If there are any things about the design that are unclear, please ping Aza about it.

	Caspy7
	Comment 18 • 14 years ago

Can right clicking please bring up the menu as well?
I rather don't want to work to click the little down arrow to bring up the list.  

The limited size of the target area is my greatest concern for this feature.

	mindugo
	Comment 19 • 14 years ago

(In reply to comment #12)
> Created attachment 485888 [details]
> Menu for the combined list
> 
> The drop-down should list tabs from all tabs in that window. See the attachment
> for how this looks.

I would prefer to have expandable/collapsible groups in this drop-down. It is much easier to navigate between groups with lots of tabs in them when they are collapsed. In such case if a group title is clicked instead of particular tab, the first tab from that group will be displayed.

	Raymond Lee [:raymondlee]
	Comment 21 • 14 years ago

Things are missing:
* Remove the all tabs button and other code
* Ensure the new popup work with sync service (Weave)
* Update the design of the combo button for Windows and Linux

Ian: If you have time, please give me some feedback for the patch

Aza/Alex: Could you provide me the UI design of the combo button for Windows and Linux

	Ian Gilman [:iangilman]
	Comment 22 • 14 years ago

Comment on attachment 492329 [details] [diff] [review]
WIP v2

Looks good so far. I don't know that much about the stuff outside of browser-tabview.js; that'll definitely need to be reviewed by someone else when the time comes. 

Also, you might check in with Aza on the full sequence of tabs. Looks pretty good to me, though I think I would put orphan tabs between unnamed groups and app tabs, so app tabs were at the very bottom. I believe that would make the order like so: 

* Active Group
* Named Groups
* Unnamed Groups
* Orphan Tabs
* App Tabs

	ithinc
	Comment 23 • 14 years ago

Is it necessary to separate App Tabs from the Active Group? I prefer Visible Tabs that "List all tabs" now shows.

	Raymond Lee [:raymondlee]
	Comment 24 • 14 years ago

Implemented the order suggested by Ian

* Active Group
* Named Groups
* Unnamed Groups
* Orphan Tabs
* App Tabs


I've only updated the style of combo button on Mac since there is only MAC design attached to this bug.  However, I find it really hard to click on the little drop arrow now because it's very small.  

@Aza/Horlander: Could you apply the patch and try it on a MAC?  Still need design for Windows and Linux.

	The 8472
	Comment 25 • 14 years ago

Stuffing all existing tabs into the dropdown would make the dropdown less useful on widescreen monitors in scenarios where you have many tabs open because it would introduce scrolling. If only the tabs of the current group are displayed then no scrolling is required in most cases.

Since hovering the mouse over the tiny scroll triangles are the only way to nagivate through the dropdown i think it should be avoided, especially since the current scrolling position can vary depending on which tab is open, which can make it less useable.

Maybe only the current tabs should be displayed in the dropdown itself and the other groups should be put as sublists (like submenus) at the end. Or they should be foldable.

	Ian Gilman [:iangilman]
	Comment 26 • 14 years ago

Comment on attachment 493343 [details] [diff] [review]
v1

Why all the code to update the menu dynamically? Are groups and tabs actually going to be coming and going while the menu is up?

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 27 • 14 years ago

This can wait until beta9, imo.

	Raymond Lee [:raymondlee]
	Comment 28 • 14 years ago

(In reply to comment #26)
> Comment on attachment 493343 [details] [diff] [review]
> v1
> 
> Why all the code to update the menu dynamically? Are groups and tabs actually
> going to be coming and going while the menu is up?

Yes, it's possible.  If you look at the current alltabs-popup code, they also handle tabOpen and tabClose.
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#3503

	Dão Gottwald [:dao]
	Comment 29 • 14 years ago

(In reply to comment #28)
> (In reply to comment #26)
> > Comment on attachment 493343 [details] [diff] [review] [details]
> > v1
> > 
> > Why all the code to update the menu dynamically? Are groups and tabs actually
> > going to be coming and going while the menu is up?
> 
> Yes, it's possible.

It's possible, yet unlikely. TabClose should probably be handled to keep the popup working. But TabOpen doesn't seem like an interesting case and may not be worth the code.

	Raymond Lee [:raymondlee]
	Comment 30 • 14 years ago

Removed the all tabs button

	Ian Gilman [:iangilman]
	Comment 31 • 14 years ago

Comment on attachment 494336 [details] [diff] [review]
V1

(In reply to comment #29)
> It's possible, yet unlikely. TabClose should probably be handled to keep the
> popup working. But TabOpen doesn't seem like an interesting case and may not be
> worth the code.

Raymond, can you slim it down to just TabClose? I'm concerned that the current implementation is trying to be comprehensive, but still doesn't cover all the cases; better to stick to the minimum necessary.

	Raymond Lee [:raymondlee]
	Comment 32 • 14 years ago

Removed the code for TabOpen.

	Ian Gilman [:iangilman]
	Comment 33 • 14 years ago

Comment on attachment 494639 [details] [diff] [review]
v1

Looks good to me.  I suggest Dao for review.

	Raymond Lee [:raymondlee]
	Comment 34 • 14 years ago

(In reply to comment #33)
> Comment on attachment 494639 [details] [diff] [review]
> v1
> 
> Looks good to me.  I suggest Dao for review.

Waiting for the combo button design for Windows and Linux so will request a review once the design is implemented on both platforms

	Kevin Hanes
	Comment 35 • 14 years ago

Beta8 has 1 bug left on it, moving our blockers to b9

	Stephen Horlander [:shorlander]
	Comment 36 • 14 years ago

(In reply to comment #34)
> (In reply to comment #33)
> > Comment on attachment 494639 [details] [diff] [review] [details]
> > v1
> > 
> > Looks good to me.  I suggest Dao for review.
> 
> Waiting for the combo button design for Windows and Linux so will request a
> review once the design is implemented on both platforms

After looking at this it looks like the patch is just using a menu-button which should pickup the default menu-buttons styling.

If that doesn't look right it would probably be outside the scope of this bug and we should address any issues in a separate bug.

	Michael Lefevre
	Comment 37 • 14 years ago

I'm not sure there's any point in raising this at this moment, but there was a bit of an outcry from people who didn't like the panorama feature, and the response (now documented in a couple of support things) is "if you don't want it, just hide the button and it won't affect anything".

I assume this change will mean that people who have hidden the panorama button will find the list tabs button disappears too.

	Dave Garrett
	Comment 38 • 14 years ago

(In reply to comment #37)
There are still people who refuse to use anything past Firefox 2. If people want something different, they'll use an addon to "make it like the old version" all over again, just like every past major Firefox version. Meanwhile, the other few hundred million users will have a browser written for them as best is possible. Besides, no functionality is being removed in this bug, just merged.

> I assume this change will mean that people who have hidden the panorama button
> will find the list tabs button disappears too.

--> bug 614904

	rob64rock
	Comment 39 • 14 years ago

This bug 611571 should block bug 596017, if what is stated in the original comment is true here: https://bugzilla.mozilla.org/show_bug.cgi?id=611571#c0

	rob64rock
	Comment 40 • 14 years ago

(In reply to comment #39)
> This bug 611571 should block bug 596017, if what is stated in the original
> comment is true here: https://bugzilla.mozilla.org/show_bug.cgi?id=611571#c0

Nevermind: "open tabs from other browser" can already be accessed directly from the "list all tabs" button!

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 42 • 14 years ago

Drugoy, you should probably read this a few times: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

	Michael Lefevre
	Comment 43 • 14 years ago

@KWierso: Think it's a bit beyond etiquette, with the level of abuse and the stealing of other people's handles/names. I suspect his bugzilla accounts are getting deleted, as each posting is from a different email address. So just as soon as someone with privileges sees the latest batch of abusive comments...

	LegNeato
	Comment 48 • 14 years ago

As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if  you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)

	Gervase Markham [:gerv]
	Comment 49 • 14 years ago

Another account disabled. Please report any further difficulties in the #bmo channel.

Gerv

	rob64rock
	Comment 50 • 14 years ago

(In reply to comment #49)
> Another account disabled. Please report any further difficulties in the #bmo
> channel.
> 
> Gerv

Where exactly is that? The troll is back here: https://bugzilla.mozilla.org/show_bug.cgi?id=598921#c43 and here: https://bugzilla.mozilla.org/show_bug.cgi?id=598991#c6

We have an infestation that just won't go away.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 51 • 14 years ago

(In reply to comment #50)
> (In reply to comment #49)
> > Another account disabled. Please report any further difficulties in the #bmo
> > channel.
> > 
> > Gerv
> 
> Where exactly is that?

#bmo is an IRC channel on irc.mozilla.org for discussing Bugzilla.Mozilla.Org.

*Please* limit comments here to discussions of this bug.

	Raymond Lee [:raymondlee]
	Comment 52 • 14 years ago

Based on the comment#36, use the default style of menu-button for the button.

	Raymond Lee [:raymondlee]
	Comment 53 • 14 years ago

(In reply to comment #52)
> Created attachment 501944 [details] [diff] [review]
> v2
> 
> Based on the comment#36, use the default style of menu-button for the button.

Passed try

	Ian Gilman [:iangilman]
	Comment 54 • 14 years ago

Comment on attachment 501944 [details] [diff] [review]
v2

Looks fine as far as I can tell; assigning to Dao for review.

	Dão Gottwald [:dao]
	Comment 55 • 14 years ago

Comment on attachment 501944 [details] [diff] [review]
v2

I haven't applied and tried the patch yet, but:

>   prefName: "browser.allTabs.previews",
>   readPref: function allTabs_readPref() {
>-    var allTabsButton = document.getElementById("alltabs-button");
>-    if (!allTabsButton)
>-      return;
>-
>-    if (gPrefService.getBoolPref(this.prefName)) {
>-      allTabsButton.removeAttribute("type");
>-      allTabsButton.setAttribute("command", "Browser:ShowAllTabs");
>-    } else {
>-      allTabsButton.setAttribute("type", "menu");
>-      allTabsButton.removeAttribute("command");
>-      allTabsButton.removeAttribute("oncommand");
>-    }
>   },

Remove this method, as it's dead now, and fix up the call sites.

	(mostly gone) XtC4UaLL [:xtc4uall]
	Comment 56 • 14 years ago

I tried the Tryserver Build (http://hg.mozilla.org/try/rev/524804dbdac3) and noticed that the Favicons for the listed Site's Tabs aren't shown anymore. Is that intended? It looks a bit strange since there seems to be a 1st Column left of Space for that Purpose, no?

	Michael
	Comment 57 • 14 years ago

I'm not sure that combining them is necessarily a good thing.  The nice thing about Panorama is that you can view and switch between only those tabs that are relevant in your current context.  (I use it in the same way that I do virtual desktops - to see only those things that are relevant to what I'm working on.)  By combining them to see all tabs at once, you lose the context sensitivity of the tab display, and wind up with far more tabs than you may have been expecting.

Note: if you do keep the merged design, it would make sense for switching to a tab in a different group to cause the group containing that tab to be displayed, rather than the current group.  That maintains the correct context for that tab, rather than risking pulling it into the current group.  (This is also consistent with OS X's Spaces behavior.)

	Raymond Lee [:raymondlee]
	Comment 58 • 14 years ago

(In reply to comment #55)
> Comment on attachment 501944 [details] [diff] [review]
> v2
> 
> I haven't applied and tried the patch yet, but:
> 
> >   prefName: "browser.allTabs.previews",
> >   readPref: function allTabs_readPref() {
> >-    var allTabsButton = document.getElementById("alltabs-button");
> >-    if (!allTabsButton)
> >-      return;
> >-
> >-    if (gPrefService.getBoolPref(this.prefName)) {
> >-      allTabsButton.removeAttribute("type");
> >-      allTabsButton.setAttribute("command", "Browser:ShowAllTabs");
> >-    } else {
> >-      allTabsButton.setAttribute("type", "menu");
> >-      allTabsButton.removeAttribute("command");
> >-      allTabsButton.removeAttribute("oncommand");
> >-    }
> >   },
> 
> Remove this method, as it's dead now, and fix up the call sites.

Fixed that. Also, it should show the favicons in the popup menu.

	Dão Gottwald [:dao]
	Comment 59 • 14 years ago

Comment on attachment 502428 [details] [diff] [review]
v2

>   prefName: "browser.allTabs.previews",

Also unused.
http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews

	Raymond Lee [:raymondlee]
	Comment 60 • 14 years ago

(In reply to comment #57)
> I'm not sure that combining them is necessarily a good thing.  The nice thing
> about Panorama is that you can view and switch between only those tabs that are
> relevant in your current context.  (I use it in the same way that I do virtual
> desktops - to see only those things that are relevant to what I'm working on.) 
> By combining them to see all tabs at once, you lose the context sensitivity of
> the tab display, and wind up with far more tabs than you may have been
> expecting.
> 
> Note: if you do keep the merged design, it would make sense for switching to a
> tab in a different group to cause the group containing that tab to be
> displayed, rather than the current group.  That maintains the correct context
> for that tab, rather than risking pulling it into the current group.  (This is
> also consistent with OS X's Spaces behavior.)

The merged design is that when you pick a tab in another group, it would hide tabs in the tabbar, switch to that group and display tabs in that group.  I believe it matches what you want, right?

	Raymond Lee [:raymondlee]
	Comment 61 • 14 years ago

(In reply to comment #59)
> Comment on attachment 502428 [details] [diff] [review]
> v2
> 
> >   prefName: "browser.allTabs.previews",
> 
> Also unused.
> http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews

Dao: do you think I should remove the whole "allTabs" object since I think it's not being used now?

	Dão Gottwald [:dao]
	Comment 62 • 14 years ago

No, only that property isn't used.

	Raymond Lee [:raymondlee]
	Comment 63 • 14 years ago

(In reply to comment #59)
> Comment on attachment 502428 [details] [diff] [review]
> v2
> 
> >   prefName: "browser.allTabs.previews",
> 
> Also unused.
> http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews

Removed that property

	Dão Gottwald [:dao]
	Comment 64 • 14 years ago

(In reply to comment #63)
> > http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews
> 
> Removed that property

You missed firefox.js.

	Dão Gottwald [:dao]
	Comment 65 • 14 years ago

Comment on attachment 502432 [details] [diff] [review]
v2

>--- a/browser/base/content/browser-tabview.js
>+++ b/browser/base/content/browser-tabview.js

>     let brandShortName = brandBundle.getString("brandShortName");
>-    let title = gNavigatorBundle.getFormattedString("tabView2.title", [brandShortName]);
>+    let title = 
>+      gNavigatorBundle.getFormattedString("tabView2.title", [brandShortName]);
>     return this.windowTitle = title;

>         self._initFrame(function() {
>-          let tabItem = self._window.GroupItems.getNextGroupItemTab(event.shiftKey);
>+          let tabItem = 
>+            self._window.GroupItems.getNextGroupItemTab(event.shiftKey);

You're adding trailing spaces here. These changes don't seem beneficial in the first place, please drop them.

	Raymond Lee [:raymondlee]
	Comment 66 • 14 years ago

Updated the patch to remove browser.allTabs.previews in firefox.js and dropped the changes mentioned in #65

	Kevin Hanes
	Comment 67 • 14 years ago

bugspam (moving b9 to b10)

	Kevin Hanes
	Comment 68 • 14 years ago

bugspam (removing b9)

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 69 • 14 years ago

Actually, after talking with Limi, we've decided that the safest way forward will be to remove the Panorama button from the toolbar by default. Users can customize their toolbar to re-add it, or use the menu options to get in/out.

I'll file a bug to track that work, but for now let's take this off the list. I suspect Ian will agree, as he'd mentioned that this was one of the riskier changes left.

	Aza Raskin [:aza] Reporter
	Comment 70 • 14 years ago

Does this mean that, by default on a vanilla install of Firefox, Panorama won't have an affordance?

	Caspy7
	Comment 71 • 14 years ago

(In reply to comment #69)
> Actually, after talking with Limi, we've decided that the safest way forward
> will be to remove the Panorama button from the toolbar by default. Users can
> customize their toolbar to re-add it, or use the menu options to get in/out.

I suppose I should point out that this will, in effect, remove Panorama from Firefox 4 for the vast majority of users (pretty well everyone we have in mind when designing).

If that IS NOT your intent, then the discussion on this topic ought to continue, allowing for the less-than-optimal-but-workable solution over the shooting-for-perfection-but-making-things-worse solution.

If that IS your intent, well, hold on to your shoelaces, I suspect you'll be hearing about this one.

	Luke Iliffe (Harlequin99)
	Comment 72 • 14 years ago

(In reply to comment #70)
> Does this mean that, by default on a vanilla install of Firefox, Panorama won't
> have an affordance?

Even less if bug 624588 is fixed. Removing the UI and keyboard access by default seems underselling a great new unique feature.

	Kevin Hanes
	Comment 73 • 14 years ago

(In reply to comment #69)
> Actually, after talking with Limi, we've decided that the safest way forward
> will be to remove the Panorama button from the toolbar by default. Users can
> customize their toolbar to re-add it, or use the menu options to get in/out.
> 
> I'll file a bug to track that work, but for now let's take this off the list. I
> suspect Ian will agree, as he'd mentioned that this was one of the riskier
> changes left.

I really think that bug 624588 is a much better solution here. 

Removing the button makes Panorama effectively undiscoverable. I can understand frustration with accidentally entering Panorama, but a button is a very intentional action. And even if someone does accidentally enter it, no harm is done; the user can exit panorama (either by button clicking, entering a tab, or hitting the close button) and be returned to their tabbed browser unharmed.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 75 • 14 years ago

(In reply to comment #73)
> but a button is a very intentional action.

Note as well that the button does have a tooltip that says "group your tabs".

I personally understand and agree with the punting of this bug to the future. I am opposed, however, to the removal of the Panorama button from the default toolbar set.

	Siddhartha Dugar [:sdrocking]
	Comment 76 • 13 years ago

Mockups don't fit with the new layout from Bug 597269

	Dão Gottwald [:dao]
	Comment 77 • 13 years ago

(In reply to comment #69)
> Actually, after talking with Limi, we've decided that the safest way forward
> will be to remove the Panorama button from the toolbar by default. Users can
> customize their toolbar to re-add it, or use the menu options to get in/out.

filed bug 626500 on this

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 78 • 13 years ago

(In reply to comment #70)
> Does this mean that, by default on a vanilla install of Firefox, Panorama won't
> have an affordance?

Yes, precisely.

Ian and I agreed that there's too much risk remaining in this bug in terms of design and implementation, and further agreed that Panorama should be shipped and made available to those who want to use it.

I'd support a change which adds the Panorama button to the toolbar when the feature is first activated from the menu, as well, or when using the keyboard shortcut. However, we're actively trying to avoid cases where users can accidentally activate Panorama due to the number of dataloss and memory usage bugs remaining and our shipping timeline.

A painful, but I think virtuous, decision.

	Paul [pwd]
	Comment 79 • 13 years ago

Given the decision, would there be time to implement bug 618791 so we still ship with some tab management by default?

	Raymond Lee [:raymondlee]
	Comment 82 • 13 years ago

Do we still want to implement this?

	Tim Taubert [:ttaubert] (inactive)
	Comment 83 • 13 years ago

FTR, bug 589465 is an alternative for this bug. Now we'd need to figure out what UI/UX folks think about these two.

	Tiger.711
	Comment 85 • 13 years ago

Also middle-click on button can instantly create new group and switch to it.

	Paul [pwd]
	Comment 86 • 13 years ago

At this point, especially given the food for thought that bug 564934 has provided, it may be a good idea to look into the idea of displaying the current tab group in a panel by default. If there are too many tabs, we can switch to list view as per what Windows Task Bar does. And should a user want additional options they can enter an immersive Panorama experience that would allow for moving tabs to different groups or creating different groups all together.

	ael
	Comment 87 • 13 years ago

This add-on does something similar: https://addons.mozilla.org/en-us/firefox/addon/tabgroups-menu/

	Joe Wilson
	Comment 88 • 13 years ago

Oh my god, Aza. You are a real destroyer.
Leave 'list all tabs' button alone!

	yayu
	Comment 89 • 12 years ago

This add-on also does something similar: https://addons.mozilla.org/en-us/firefox/addon/pano/

	Tim Taubert [:ttaubert] (inactive)
	Comment 90 • 11 years ago

Panorama is not meant to be discoverable and will not be anytime soon, if at all. This functionality can certainly be provided by add-ons so I don't think we want to have this as a core feature.