I'll let @chad have the final word on this, but I don't think we have any plans to pursue it. We previously had a persistent "applications" side menu/dock thing, which wasn't quite the same, but was a lot less useful than we'd thought it would be and which many users deeply hated.

The quickest way to jump to rarely-used applications is to use the "Search" menu -- type the application name or a part of its description, and it should be the first hit.

I think long term we'd likely move Quick Create into a generic bookmarks type tool, which you could dock creation forms, workboard links, burnup charts, apps, whatever you like... But I think that's some ways off. For now most browsers support folders in the bookmarks bar and between being able to customize that or use the stock Phabricator search, getting to common apps is pretty easy.

Thanks for @epriestley I have started using the keyboard shortcuts more.

@chad a global bookmark system seems like a better idea, checkout the global bookmark on the AWS console, I've found that useful.

As mentioned in T9775, we think this would be a very useful feature for those of us who need to work on multiple projects. Having it tied to the flags application would make it awesomely customizable (and make Flags a much more useful application).

You were thinking about doing this one first, then Home later, right?

I think the pathway is basically:

• Add a nullable customPHID to MenuItemConfiguration.
  • By default (and for all existing items) this will be null, meaning "this item is part of the global/default menu".
  • When users add menu items, customPHID will be set to their user PHID.
• Figure out some kind of PHID we can use for the profilePHID on these items. Maybe it's reasonable to just create a small application for this? That would let us use the application PHID, and let administrators uninstall the application to remove the menu if they want to get rid of it for some reason. However, it could also reasonably be a settings panel, and maybe that's cleaner. We could just use the Settings application PHID for now in that case -- it would be easy to migrate later, and it seems unlikely that we'll want a different customizable menu in Settings later. Removing this menu doesn't seem terribly useful and I don't think there are any other things we gain by turning this into a real application. Although turning the existing edit workflow -- which I think is a Controller that assumes it can have the whole page -- into a Settings panel might also be hard.
• Whichever way that goes, swap the menu generation to use a ProfileMenuQuery next I guess.
• Then work on the edit stuff? It mostly needs to learn about "user" vs "global" modes, and set customPHID appropriately.
• Then fix up the generation to grab global + user items and combine them in the right order.

I'm for whichever is easiest, since the other will fall in line quickly after.

I'm not actually sure which will end up being easier, I think they have like 95% of the same problems. Quick Create probably is a bit easier, though.

Just for my own understanding:

• QuickCreate will use SettingsPHID
• Users who customize theirs will use SettingsPHID as profileObject and UserPHID as customObject
• We load in custom / global.
• Admins who customize use SettingsPHID as profileObject and no customObject
• Some sort of UI for admins to set the global which just starts as builtIns

Yep, that looks good to me.

Started building and insanely easier as an application. "Favorites" unless you have a better suggestion. Seems more flexible.

I think I need to make PhabricatorProfileMenuItem files for each "default" I want to ship?

• Create Task
• Create Project
• Create Repository

???????

I also think you have some special magic that turns "Create Task" into a mini-menu automagically - we can probably ditch that outright?

You should be able to return a list of appropriately configured PhabricatorEditEngineProfileMenuItem objects as builtins, rather than defining a new class for each application -- since "Create Task" is just "EditEngine link to the create task form", etc.

we can probably ditch that outright?

Yeah, let's get rid of this. I think it's fine to make users update the menu explicitly after major workflow changes, since these are very rare.

oh ok, I think I can do that

One thing I haven't been able to build is the ProfileMenuItemConfigurationQuery -> ActionView

private function renderFavoritesDropdown(PhabricatorUser $viewer) {

  // Beg for halps
  $items = array(
    array(
      'name' => 'Create Task',
      'href' => '#',
    ),
    array(
      'name' => 'Create Project',
      'href' => '#',
    ),
    array(
      'name' => 'Create Repository',
      'href' => '#',
    ),
  );

  $view = id(new PhabricatorActionListView())
    ->setViewer($viewer);
  foreach ($items as $item) {
    $action = id(new PhabricatorActionView())
      ->setName($item['name'])
      ->setHref($item['href']);
    $view->addAction($action);
  }

  return $view;
}

Any hints?

I think there are two approaches:

1. Reuse the existing code which generates PHUIListItemView objects, not PhabricatorActionView objects.
2. Or, extend MenuItem classes so they can build either PHUIListItemView objects or PhabricatorActionView objects.

If possible, I think approach (1) is better. You could do it in a couple ways:

• Build the dropdown itself out of PHUIListItemView objects.
• Build PHUIListItemView objects first, then create PhabricatorActionView from them, then build the menu.

There's also a hybrid approach, like:

• In most cases, build PHUIListItemView objects and then automatically turn them into PhabricatorActionView objects, but have some kind of method to let the MenuItem do something different if it needs to.

But I think it should be possible to just reuse all the existing code without modification, since I think PHUIListItemView supports everything PhabricatorActionView supports?

So maybe something like:

// Build a AphrontSideNavFilterView, normally.
$filter_view = id(new FavoritesMenuEngine())
  ->setViewer($viewer)
  ->setProfileObject($favorites_application)
  ->buildNavigation();

// Get the PHUIListView from it.
$menu_view = $filter_menu->getMenu();

// Get the PHUIListItemViews from that.
$item_views = $menu_view->getItems();

// Convert the ListItemViews into ActionViews.
$action_views = array();
foreach ($item_views as $item_view) {
  // I think this doesn't exist yet, you'd have to write it.
  $action_views[] = PhabricatorActionView::newActionViewFromItemView(
    $item_view);
}

Yeah I think we shouldn't have two types of lists.

Yeah, I'm not aware of any real difference between them or good reason to have both. Maybe I'm forgetting something but I'm pretty sure we can merge them eventually.

This diff will be a wondrous, wandering tale or action, adventure, mystery, intrigue, and touch lots of random stuff that should have been broken apart.

phuix-js builds phabricator-action-view, so that's what I was planning to be king.

ahahhahaha

hahaha
ha
h

Resign Header -> Redesign Lists -> Redesign ProfileMenu

please also add "close menu" and a label that says "menu items" and help text that says "click an item to activate it"

It also occurs to me that Project profile menus already show up in a main menu dropdown on mobile, so we must have some PhabricatorActionView::newActionViewFromItemView(...) sort of code in there somewhere.

This is in a reasonable state, will follow up with a new task on errata.