Skip to content

feat(core): allow pinning apps inline in the navigation bar#61825

Draft
MiMoHo wants to merge 2 commits into
nextcloud:masterfrom
MiMoHo:feat/61274/pinned-navigation-apps
Draft

feat(core): allow pinning apps inline in the navigation bar#61825
MiMoHo wants to merge 2 commits into
nextcloud:masterfrom
MiMoHo:feat/61274/pinned-navigation-apps

Conversation

@MiMoHo

@MiMoHo MiMoHo commented Jul 4, 2026

Copy link
Copy Markdown

Summary

Implements #61274: users can pin selected apps to show them inline in the top bar for one-click switching, while everything else stays in the app menu popover. The default stays exactly as it is today — nothing changes unless a user pins apps.

State Screenshot
Two pinned apps, active app (Files) shows the indicator, current-app trigger hidden header with pinned apps
Labels on hover/focus, like the pre-NC34 navigation header on hover
Pin toggles in the existing personal "Navigation bar settings" settings section

How it works

  • Pinned entries reuse the pre-NC34 AppMenuEntry/AppMenuIcon components, restored from stable33 (icon, label on hover/focus, active indicator, unread dot) and adjusted to the 44px header (--header-height-based sizing, active indicator at 4px).
  • The inline list claims the free space between the menu triggers and the centered search (flex: 1 1; width: 0) and is measured with useElementSize; it only renders as many entries as fit, so it can never push the centered search around (same approach stable33 used for overflow). Below 1024px the list is hidden, same breakpoint as the current-app button — the popover covers app switching there.
  • The current-app trigger is hidden while the active app is visible in the pinned list (the active entry already shows the location); it stays for settings pages and unpinned apps.
  • Storage: user preference core/apps_pinned (JSON list of navigation entry ids), saved through the same provisioning API route as apporder and validated in the theming BeforePreferenceListener. Order of the pinned entries follows the existing user-sortable app order.
  • Pin toggles are added to the existing AppOrderSelector rows (opt-in via showPin prop, so the admin "default apps" usage is unchanged).

Testing

  • core/src/tests/components/AppMenu.spec.ts: 7 new cases (inline rendering follows nav order, unknown ids ignored, no list when nothing is pinned, width-capped rendering, current-app hiding/keeping incl. the truncated-away case) — 15/15 pass.
  • Verified manually against a local instance: pin/unpin round-trip through the settings UI (OCS 200, reload hint shown, header updates after reload), active indicator, hover labels, settings pages keep the "Settings" trigger.

Open questions for design review 🙏

Opening as draft to align on the design first (feedback from the #61274 / #59888 crowd very welcome):

  1. Is per-user pinning in personal settings the right scope, or should there also be an admin-set instance default (e.g. defaultPinnedApps in theming)?
  2. --app-menu-entry-growth from the NC33 entry was kept, but at 44px header height long labels still ellipsize on hover — acceptable, or should the hover-label mechanic be simplified (e.g. plain tooltip)?
  3. Should the current-app trigger stay visible even when the active app is pinned (i.e. never hide it)?
  4. Cap on the number of pinned apps? Currently the width measurement is the only limit (extra pins simply don't render).

Resolves #61274

🤖 Generated with Claude Code

@sedric

sedric commented Jul 5, 2026

Copy link
Copy Markdown

Nice improvement !

For the questions asked :

  1. Maybe a bit of both ? Like admin set the default, while allowing per-user setting ?
  2. I think it's acceptable, it was is the past and never was that big of an issue
  3. No pref
  4. Cap is not future-proof design. If it's hidden, we can still get it from the waffle menu

@mwerle

mwerle commented Jul 5, 2026

Copy link
Copy Markdown
  1. Admin-enforced pinning: no. Admin-defaulted pinning: yes. Basically allow users to adjust their workspace, but give admins a way to "advertise" newly installed apps or apps which are expected to be commonly used in a particular environment.
  2. no opinion
  3. no opinion
  4. If some app icons are hidden, this should be indicated in some way ("...", "»" ?). If all app icons remain in the drop-down "waffle" menu regardless of whether they are pinned or not, they can still be accessed. But a big no to an enforced limit. People with bigger displays would be artificially restricted.

I'd suggest that to support people migrating from older versions of Nextcloud and used to the Nextcloud interface, the default apps included in most/all installations should be pinned by default (calendar, files, photos, mail, contacts, etc). Or perhaps pin them by default when migrating from a previous install, but not when doing a new install. Dunno.

I'd also like to see an option to get rid of the new search bar and make it an icon again to make more space for app icons for the people who rarely/never use the unified search. I am far more likely to use an app-specific search.

Great work and thank you for taking on board the community feedback.

@joskapista44

joskapista44 commented Jul 5, 2026

Copy link
Copy Markdown

Thank you for your work,

  • I think if you have less apps, labels on hover/focus is not necessary. Please add the option to turn it on/off
  • Please also add the same options for the waffle menu: ability to unpin something or everything from the waffle menu. If you unpin all from there, you also hide waffle menu with it (no point to keep an empty menu)

1: It would be nice as you mentioned: Default settings in the admin interface, with the option (on/off) for regular users to modify them.
2: I think the tooltip is a good idea, the old way wasn't a clean design
3: yes - But if you make an option also on the waffle menu as I mentioned before with the ability of unpin items from the waffle, you give the more options to the users to customize their nextcloud for almost free
4: NC33 + Custom menu behavior was perfect: as you resize the window, if the icons don't all fit, three dots appear, which let you access the ones that didn't fit on the screen.
614401859-33ed5656-41ee-4277-8e48-9a6b63cf7efc

@luxzg

luxzg commented Jul 5, 2026

Copy link
Copy Markdown

I am all for options, so I'd summarize:

  • admin having ability to pre-pin / default the pins, or indeed set the defaults for all settings
  • user being able to override any of it
  • ability to set labels to hover/permanent/no-labels
  • ability to set search to search field/just icon/no search
  • ability to pin any apps and as many apps as possible (overflow being indicated by ellipsis depending on screen size/resolution, dynamically)

Basically - give people customisation options. Menu bar is like system tray for the OS, waffle menu is like "Start" menu of the OS. They are very personal, and many different people use this product, so give options to customise such very important parts of UI.

I am still not on NC 34 and I am also using Custom menu mentioned above, and would prefer this being part of the core Nextcloud experience, preferably not waiting for NC 35 (link to app.for those that don't know about it : https://apps.nextcloud.com/apps/side_menu )

@kernitus

kernitus commented Jul 5, 2026

Copy link
Copy Markdown

If all apps are pinned there is no need to waste space showing the waffle menu

@Moini

Moini commented Jul 5, 2026

Copy link
Copy Markdown

Thank you for addressing this, it's a huge relief to learn that navigation might go back to 'normal' again soon.

Now some feedback:

Search field size / number of icons
I'd like to be able to shrink the search field size. Even in your screenshot where it's on the right, it's unnecessarily huge. I never use it, because I know what I want and where to find it. It also looks somehow out of place because of its size and the new location.
So it would be nice if it were to shrink down to a reasonable minimal size when more icons are added. Something like 4 icons width would be fine.

An artificial limit on the number of pinned apps could collide with custom CSS that makes the icons smaller or larger, and with different screen sizes and zoom levels. I would not enforce that on the code side, but make it dependent on available space and have the 'rest' reside in an overflow menu at the end, rather than at the beginning of the list (where it is placed more logically, as these are those that would be rarely / never used).

Convenience function for switching to the old menu style

To be able to quickly switch back to the normal, previous behavior, an 'add all' quick toggle would be helpful. Otherwise, it takes quite a long time to fix something that Nextcloud designers broke for many.

Text on hover

I never liked the labels on hover, it looked and felt pretty weird. Title would be great.

Admin default

Yes, please. Not enforced, but automatically set.

Current app trigger

I don't understand what that means.

Feature request (likely out of scope)

Could it be possible to set the color? My own menu color currently and for quite some time for some reason is black / grey, while it should be white (and for the admin account, it actually is white, and I have no idea why there's a difference).

@dbielz

dbielz commented Jul 6, 2026

Copy link
Copy Markdown

Thanks for addressing this from my side too, I still struggle every day with the new design.

As for your questions:

  1. I'm afraid, an admin setting would be necessary as well, from my experience (as admin), users tend to complain, but most of them are not willing to find out, how they can change annoying things themselves, if it's not obvious. So my opinion: let the admin configure the default, but give the users the option to customize.
  2. I have no idea, what this is about. But if it is about showing labels on hovering: definitively yes. Some of the icons are not very 'speaking', so I think it's important to have a way to see what an icon stands for.
  3. again, I'm not sure what you mean by this. If it's about showing or hiding the waffle menu if all apps are pinned: definitively yes, please hide the waffle menu. Maybe this is even easier: Add an option whether to generally use the waffle menu or not at all would make it easier than having to pin 24 apps (and every app added in the future as well).
  4. There will always be smaller and bigger displays, and I think, trying to find that one solution fitting to all sizes unnecessarily restricts many for a (which?) benefit of few. So: no, cap is not desirable. But I would opt for an overflow indicator like #issuecomment-4884288391 from #@mwerle stated. By the way, I didn't observe this as a problem up to now, how was it solved before?

Why at all must this be completely redesigned, wouldn't it be easier to set an option 'waffle menu yes or no' and leave it as it was before?

As for the search button: I would very very very much appreciate if it would return to the small size from before. I never (or hardly ever) use it, so for me it's a complete waste of space this way.
And why does one familiar control element (button) has to look like a different familiar element (input field)? This undermines recognizability, which is a central factor in usability. But where's the benefit of it?

So please please please return to the 'button' design.

@susnux susnux added the community pull requests from community label Jul 6, 2026
@MiMoHo

MiMoHo commented Jul 6, 2026

Copy link
Copy Markdown
Author

Thanks a lot for all the feedback! Quick status update and answers to the open points.
This draft deliberately stays scoped to "per-user pinning, default unchanged" until the design team has reviewed it; the recurring wishes are collected below as agreed follow-ups so nothing gets lost.

Where things stand

  • The draft implements exactly what the description says: opt-in per-user pinning via the personal "Navigation bar settings", inline entries restored from the pre-NC34 components, width-capped rendering, default unchanged.
  • There is no design-team review yet. I don't want to widen the scope before that happens — it keeps the PR reviewable and avoids redoing work if design prefers a different direction.
  • @dbielz "why redesign at all, why not a waffle on/off option": that was proposed and declined in Option to Restore NC33 Menu Bar in NC34 #61561 (closed as duplicate of Option to use Waffle menu or links displayed normally #61274) — per-user pinning is the compromise the team accepted, which is what this PR builds.

Consensus on my four questions so far (thanks @sedric @mwerle @joskapista44 @luxzg @kernitus @Moini @dbielz):

  1. Admin defaults — clear yes from everyone, as a default, never enforced; users keep the last word. Plan: a defaultPinnedApps theming setting as a follow-up (or in this PR, if the design team prefers).
  2. Hover labels — keep them; an on/off option was requested twice and is noted, but depends on the design decision (grow-label vs. plain tooltip).
  3. Current-app trigger — no strong opinions, so I'll keep the current behaviour (hidden while the active app is visible in the bar).
  4. Cap — unanimous no. Width-based rendering stays the only limit; an NC33-custom-menu-style "…" overflow indicator (like the screenshot @joskapista44 posted) is the agreed follow-up. Until then, pins that don't fit simply don't render — every app always stays reachable in the app menu.

@dbielz @Moini — what questions 2 and 3 meant:

  • Q2 is about the labels of the pinned entries, which appear on hover/focus (second screenshot in the description). At the 44px header height a long app name gets cut off with "…" — the question is whether that's acceptable or whether a plain tooltip would be better. It is not about removing labels.
  • Q3: since NC34 the header shows a button with the icon + name of the app you are currently in (next to the logo). When the active app is pinned, it is already visible and highlighted in the bar, so that extra button is redundant — the draft hides it in that case (and keeps it on settings pages and for unpinned apps). The question was whether hiding it is OK.

The other requests and where they land:

Request Status
Admin-set default pins (not enforced) Agreed — follow-up, or this PR after design OK
"…" overflow indicator Agreed follow-up
Hide the app-menu (waffle) button when everything is pinned Needs design input: below 1024px the inline list is hidden and the popover is the only app navigation, so it can't disappear unconditionally. Hiding it only while every app fits inline is doable as a follow-up.
"Pin all" quick toggle (@Moini) Good idea and cheap to add to the settings section — follow-up candidate
Pin the classic default apps when upgrading from ≤33 (@mwerle) Touches the upgrade path — I'd leave that to a separate discussion
Smaller search field / search as an icon Out of scope here: this PR never moves or resizes the search, the pinned list only claims the free space next to it. That's worth its own issue if there isn't one yet.
Unpinning entries from inside the app menu (@joskapista44) Different feature (changes what the popover shows) — separate issue
Menu bar colour (@Moini) Unrelated to this PR — sounds like a theming bug, please file it separately with your setup details

Next step: waiting for a design review — that's why this is a draft. Once it's in, I'll finalize the scope, take the PR out of draft, and file the agreed follow-ups as issues so they are trackable.

@joskapista44

Copy link
Copy Markdown

Hide the app-menu (waffle) button when everything is pinned Needs design input: below 1024px the inline list is hidden and the popover is the only app navigation, so it can't disappear unconditionally. Hiding it only while every app fits inline is doable as a follow-up.

Only one thing with this: In my setup the nextcloud logo leads to the dashboard. And there is also a dashboard icon by default which is a duplication, so I removed it with the custom menu app. With the version you wrote if I unpin the dashboard icon, the waffle menu will appear. So better would be to be able to unpin elements from the waffle menu also, and if there is no app left there hide the menu icon. Under 1024px you can still use the old style: three dots at the end and a drop down menu with the hidden icons.

MiMoHo added 2 commits July 6, 2026 18:59
Bring back one-click app switching next to the app menu launcher:
users can pin selected apps in the personal 'Navigation bar settings'
section. Pinned entries render inline in the top bar following the
user-defined app order, everything else stays in the app menu popover.

- The inline entries reuse the pre-NC34 AppMenuEntry/AppMenuIcon
  components, restored from stable33 (icon, label on hover/focus,
  active indicator, unread dot), adjusted to the 44px header.
- The list is measured (useElementSize) and only renders as many
  entries as fit, so it can never collide with the centered search.
- The current-app trigger is hidden while the active app is visible
  in the pinned list, as the active entry already shows the location.
- Pinned entries are stored as user preference core/apps_pinned and
  saved through the same provisioning API path as apporder, validated
  in the theming BeforePreferenceListener.
- Pin toggles live in the existing personal 'Navigation bar settings'
  section next to the app order controls.

Resolves nextcloud#61274

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Assisted-by: ClaudeCode:claude-fable-5
Signed-off-by: MiMoHo <37556964+MiMoHo@users.noreply.github.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Assisted-by: ClaudeCode:claude-fable-5
Signed-off-by: MiMoHo <37556964+MiMoHo@users.noreply.github.com>
@Moini

Moini commented Jul 6, 2026

Copy link
Copy Markdown

@MiMoHo Thank you! After the explanation, I agree with your suggestion to not show / highlight the 'current app' twice.

@MiMoHo MiMoHo force-pushed the feat/61274/pinned-navigation-apps branch from 7349b22 to 26ae9a1 Compare July 6, 2026 17:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community pull requests from community

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Option to use Waffle menu or links displayed normally

9 participants