rename *related to *all+*related
instead of |cardtype|+*related pointing to subtabs appearing on |cardtype| cards, use |cardtype|+*type+*related
enable subtabs to appear when other sets are plussed to *related
Maybe:
Unlike other settings, subtabs of more specific sets do not replace more general ones, they are all added. More specific ones are leftmost however, so custom subtabs specified in foo+*self+*related go first.
I think we need to generalize this idea to all the subtabs. One approach that I was playing with uses a setting that is a pointer card, and it uses the tagname or each pointer for the 'name' of the subtab, and the contents as a template. That way one setting controlls the whole tab. -- Gerry Gleason
The only other tab that has subtabs is Edit (well, and Options, but that's going away). You want to make the subtabs under Edit customizable?
Ah, I'm guessing you just mean the tabs altogether? We talked about doing that when we made the Related subtabs customizable but didn't ticket it. Lots to work out to do that, but, something like reimplement tabs as cards. Whether or not we do this for View, Changes, etc. it would definitely be nice to let people Wagneer tabbed interfaces on included cards (overriding the default set of tabs, whether they are hard-coded or Wagneered).
--John Abbe.....Thu Feb 17 19:16:03 -0800 2011
Right, I mean something more inclusive like that. Consistent with "everything is a card" and actually adding a new tab was part of an extension I wrote pre-API and I want to have a more consistent way to add it.
I guess another way of looking at this is that "related" should be added using an API feature that others can use to add their own tabs. Refactoring the base set of tabs (besides related) could be done later if at all.
--Gerry Gleason.....Mon Feb 21 03:34:09 -0800 2011
closing because this is gone, though making menus wagneerable is still a central issue.
--Ethan McCutchen.....2013-02-25 00:05:58 +0000
+discussed in support tickets
+relevant user stories