Show current organization's name and logo atop main menu #1937

rajveermalviya · 2025-10-22T14:39:33Z

Light	Dark

Figma: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=2940-48987&p=f&m=dev
Fixes: #1037

alya · 2025-10-23T17:14:30Z

Hm, looking at this now, I don't like the "Organizations" button there. It's not immediately apparent what organizations it's referring to/why.

Where does it go? The account switcher?

rajveermalviya · 2025-10-23T18:03:36Z

Where does it go? The account switcher?

Correct in the current revision it goes to the account switcher button, also the Figma design doesn't have a separate "Switch account" button in the main menu.

alya · 2025-10-23T18:08:32Z

Can you just click on the org name itself to switch accounts?

alya · 2025-10-23T18:09:00Z

(If we're moving the account switching action to this new top line, we'll want to remove the "switch account" option in the same PR.)

chrisbobbe

Thanks! Comments below, and see also Alya's feedback (mentioning it so it doesn't get lost in the thread).

chrisbobbe · 2025-10-23T22:58:26Z

lib/model/store.dart

-  String? get realmName => account.realmName;
-
-  Uri? get realmIcon => account.realmIcon;
+  // The `account` is populated with the `realmName` before
+  // PerAccountStore is created, so this should never be null.
+  // See `UpdateMachine.load`.
+  String get realmName => account.realmName!;
+
+  // The `account` is populated with the `realmIcon` before
+  // PerAccountStore is created, so this should never be null.
+  // See `UpdateMachine.load`.
+  Uri get realmIcon => account.realmIcon!;


store: Make realmName and realmIcon getters non-null

Commit-message nit: "non-nullable", right? Also the commit message repeats reasoning that's already clear from added code comments, so we can remove it from the commit message.

chrisbobbe · 2025-10-23T23:02:12Z

test/widgets/home_test.dart

    testWidgets('_AboutZulipButton', (tester) async {
+      tester.view.physicalSize = Size(1080, 1920);
+      prepareBoringImageHttpClient();
      await prepare(tester);
      await tapOpenMenuAndAwait(tester);
      await tapButtonAndAwaitTransition(tester, find.byIcon(ZulipIcons.info));
      check(find.byType(AboutZulipPage)).findsOne();
+      debugNetworkImageHttpClientProvider = null;
    });


Rather than thinking through what's accomplished with the numbers 1080 and 1920 and whether they're correct, I'd rather just scroll until the button is in view:

testWidgets('_AboutZulipButton', (tester) async { prepareBoringImageHttpClient(); await prepare(tester); await tapOpenMenuAndAwait(tester); await tester.ensureVisible(find.byIcon(ZulipIcons.info)); await tapButtonAndAwaitTransition(tester, find.byIcon(ZulipIcons.info)); check(find.byType(AboutZulipPage)).findsOne(); debugNetworkImageHttpClientProvider = null; });

That's simpler and more transparent, and also adds some coverage of the scrolling logic; it seems like a win-win :)

chrisbobbe · 2025-10-23T23:04:44Z

lib/widgets/home.dart

+    final designVariables = DesignVariables.of(context);
+    final store = PerAccountStoreWidget.of(context);
+
+    final realmIconUrl = store.tryResolveUrl(store.realmIcon.toString());


Most of this line seems like code we'd rather not need to recite whenever we need the realm icon—should be possible to encapsulate it in PerAccountStore (maybe even Account?) where we have access to the realm URL.

chrisbobbe · 2025-10-23T23:05:49Z

lib/widgets/home.dart

+      padding: const EdgeInsets.only(top: 6),
+      child: Row(children: [
+        Expanded(child: Padding(
+          padding: const EdgeInsets.fromLTRB(12, 6, 4, 6),


Use EdgeInsetsDirectional.fromSTEB here, for RTL support.

chrisbobbe · 2025-10-23T23:09:32Z

lib/widgets/home.dart

+                MaterialWidgetRoute(page: const ChooseAccountPage()));
+            },
+            style: TextButton.styleFrom(
+              padding: const EdgeInsets.fromLTRB(8, 7, 14, 7),


(Same comment about EdgeInsetsDirectional.fromSTEB.)

chrisbobbe · 2025-10-23T23:37:08Z

lib/widgets/home.dart

+                ? RealmContentNetworkImage(realmIconUrl)
+                : const SizedBox.shrink()),


When the icon URL doesn't parse for whatever reason, and also when it does but the network request fails, how about we show an empty rounded square colored by DesignVariables.avatarPlaceholderBg? Maybe we could have a reusable RealmIconImage widget that takes care of that, much like AvatarImage takes care of choosing a placeholder (which it'll do in more cases with #1558).

chrisbobbe · 2025-10-23T23:42:25Z

lib/widgets/home.dart

+/// The main-menu sheet.
+///
+/// Figma link:
+///   https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=11367-20647&t=lSnHudU6l7NWx0Fa-0


This URL is taking me to the "Read receipts" sheet; do you reproduce? (Could be a Figma issue)

chrisbobbe · 2025-10-23T23:47:00Z

lib/widgets/home.dart

+              backgroundColor: Colors.transparent,
+              overlayColor: Colors.transparent,
+              splashFactory: NoSplash.splashFactory,
+              shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(10)),


This border radius shouldn't make a difference, with a transparent background/overlay/etc., right? I see it in the Figma, but it looks accidental there, too; I think we can leave it out without comment.

rajveermalviya · 2025-10-28T15:21:39Z

Thanks for the reviews @chrisbobbe, @alya.
Pushed an update, and also updated the screenshots in the description, PTAL.

alya · 2025-10-28T21:54:59Z

Seems reasonable to me, thanks! Open to feedback from @terpimost if he has another suggestion.

chrisbobbe

Thanks! Comments below.

chrisbobbe · 2025-11-04T00:24:10Z

lib/model/store.dart

  ///
  /// This returns null if [reference] fails to parse as a URL.
-  Uri? tryResolveUrl(String reference) => _tryResolveUrl(realmUrl, reference);
+  Uri? tryResolveUrl(String reference) => _tryResolveUrlStr(realmUrl, reference);


store [nfc]: Rename _tryResolveUrl to _tryResolveUrlStr

flutter analyze is complaining to me at this commit:

Analyzing zulip-flutter... info • Unnecessary 'this.' qualifier • lib/model/emoji.dart:229:25 • unnecessary_this info • Unnecessary 'this.' qualifier • lib/model/emoji.dart:234:26 • unnecessary_this 2 issues found. (ran in 3.5s)

chrisbobbe · 2025-11-04T00:40:02Z

lib/model/store.dart

 /// Like [Uri.resolve], but on failure return null instead of throwing.
-Uri? tryResolveUrl(Uri baseUrl, String reference) {
+Uri? tryResolveUrlStr(Uri baseUrl, String reference) {


Can we move this helper to a different file, like maybe lib/basic.dart? It's a convenience function encapsulating some control flow (a try/catch) and doesn't depend on details of a store.

Ditto the new, parallel helper that you're adding, which takes a Uri instead of String for reference.

Or, alternatively, I think we could just make both of these helpers private.

chrisbobbe · 2025-11-04T00:41:36Z

test/widgets/content_test.dart

      check(() => Uri.parse(expectedImages.single.srcUrl)).throws<void>();
-      check(tryResolveUrl(eg.realmUrl, expectedImages.single.srcUrl)).isNull();
+      check(tryResolveUrlStr(eg.realmUrl, expectedImages.single.srcUrl)).isNull();


The rename brings attention to this existing check 🙂 which looks redundant with the one above it (.throws<void>()). I think we're free to remove it.

chrisbobbe · 2025-11-04T00:55:25Z

lib/widgets/home.dart

+
+    return Padding(
+      padding: const EdgeInsets.only(top: 6),
+      child: AnimatedScaleOnTap(


I think this would look better without the AnimatedScaleOnTap effect. It looks like two things that are moving, rather than one thing that's resizing.

I think we should reserve this effect for buttons that are a rounded-rectangle surface:

Thoughts @alya?

For touch feedback here, how about opacity? Per Vlad's suggestion at #mobile-design > all channels view design @ 💬:

we could use opacity by default to indicate touch if its not provided

Agreed that the effect in that screen capture isn't working. Trying Vlad's suggestion sounds good to me.

chrisbobbe · 2025-11-04T03:23:46Z

lib/widgets/home.dart

+              child: Icon(ZulipIcons.arrow_left_right,
+                size: 19,
+                color: designVariables.icon)),


I wonder if this would be a good place to use ZulipIconButton.

chrisbobbe · 2025-11-04T03:30:18Z

lib/widgets/home.dart

+                  ).merge(weightVariableTextStyle(context, wght: 600)))),
+              ]))),
+            Padding(
+              padding: EdgeInsetsDirectional.fromSTEB(8, 7, 14, 7),


I wonder if the end padding should be 12px, to match the padding before the org icon?

This 14px value comes from the Figma, but the Figma uses end-aligned text, and I think the 14px value might be tailored to that case. Also maybe the 7px vertical padding? Seems like it would be simpler, and logical, if we just wrapped the whole row with 12px horizontal padding and 6px vertical padding, and said spacing: 12 (or some other appropriate value) on the Row.

rajveermalviya · 2025-11-10T19:24:03Z

Thanks for the review @chrisbobbe! Pushed an update, PTAL.

chrisbobbe · 2025-11-10T19:37:14Z

cc @alya

Ah hmm, with the ZulipIconButton the row (including padding) is now 52px tall, and it looks like too much vertical whitespace to me:

Can we remove the 6px top and bottom padding on just the ZulipIconButton, so the row is 40px like in the Figma?

Also, seeing the doubled touch feedback (everything faded, and also a gray highlight appearing on ZulipIconButton)—

—what if we forget about making the org name/icon tappable, and instead just use ZulipIconButton straightforwardly as a "Switch account" button, with a tooltip saying that?

alya · 2025-11-10T20:11:34Z

Hmm, yeah, that double feedback is odd. @terpimost might have opinions here, but I don't feel strongly about the whole row being a switcher.

rajveermalviya · 2025-11-13T15:09:34Z

Thanks for the review @chrisbobbe! Pushed an update, PTAL.

chrisbobbe

Thanks! Just small comments below.

chrisbobbe · 2025-11-13T19:58:47Z

lib/widgets/home.dart

+  }
+}
+
+class _MainMenuHeader extends StatefulWidget {


This can be a StatelessWidget now, right?

chrisbobbe · 2025-11-13T20:00:06Z

lib/widgets/home.dart

+            return child;
+          },
+          errorBuilder: (_, e, st) {
+            debugLog('$e\n$st'); // TODO(log)


Wrap this in an assert (see debugLog's dartdoc)

chrisbobbe · 2025-11-13T20:01:59Z

lib/widgets/home.dart

+        Tooltip(
+          message: zulipLocalizations.switchAccountButtonTooltip,
+          child: ZulipIconButton(
+            icon: ZulipIcons.arrow_left_right,
+            onPressed: () => _onPressed(context))),


Could we factor the tooltip text as a param on ZulipIconButton that just gets passed along to the IconButton in the implementation?

rajveermalviya · 2025-11-14T08:20:35Z

Thanks for the review @chrisbobbe! Pushed an update, PTAL.

chrisbobbe

Thanks, LGTM! Marking for Greg's review.

chrisbobbe · 2025-11-18T19:22:17Z

lib/widgets/home.dart

+          icon: ZulipIcons.arrow_left_right,
+          onPressed: () => _onPressed(context),
+          tooltip: zulipLocalizations.switchAccountButtonTooltip),


nit: I would put icon and tooltip next to each other, because they're both communicating the button's meaning

Ah makes sense, I was trying to match the parameter ordering. Pushed a revision with this addressed.

gnprice

Thanks @rajveermalviya for building this, and thanks @chrisbobbe for the previous reviews!

Comments below. I'm not quite done reading the last commit (and haven't yet looked at the UI); but about to go AFK for now, so here's what I have so far.

gnprice · 2025-11-22T01:31:34Z

lib/model/store.dart

+  // The `account` is populated with the `realmName` before
+  // PerAccountStore is created, so this should never be null.
+  // See `UpdateMachine.load`.
+  String get realmName => account.realmName!;


This reasoning makes sense.

It's kind of non-local, though: the reader has to go look at that faraway piece of code (700 lines later in this file, plus it probably ultimately belongs in a separate file), and then also has to wonder if there might be any other code path that leads to instantiating one of these without going through there.

(And indeed there are such code paths in tests. So if any of those could use an Account where one of these fields is null, then that could lead to puzzling behavior in a test somewhere.)

To mitigate that, how about putting an assertion to this effect up at the constructor? Then

this comment can go at that assertion;

the assertion helps give confidence that, whether or not the comment's reasoning is airtight, the invariant does hold in practice;

here at this line, the reader only has to consult the constructor a few lines up, rather than think about anything wider.

Or better: put the assertions at the top of PerAccountStore.fromInitialSnapshot, to go alongside the similar assertions we already have there.

(That's a little farther away from where we use the invariant here; but we already have other getters here relying on similar invariants checked there.)

gnprice · 2025-11-22T01:36:46Z

lib/model/store.dart

+/// Like [Uri.resolve], but on failure return null instead of throwing.
+Uri? _tryResolveUrl(Uri baseUrl, Uri reference) {
+  try {
+    return baseUrl.resolveUri(reference);


Suggested change

/// Like [Uri.resolve], but on failure return null instead of throwing.

Uri? _tryResolveUrl(Uri baseUrl, Uri reference) {

try {

return baseUrl.resolveUri(reference);

/// Like [Uri.resolveUri], but on failure return null instead of throwing.

Uri? _tryResolveUrl(Uri baseUrl, Uri reference) {

try {

return baseUrl.resolveUri(reference);

right?

Also: can [Uri.resolveUri] actually throw?

Skimming the implementation, I think it can't (short of a bug in the implementation) — there's no explicit mention of throwing, and nothing that looks like it's meant to sometimes throw. And semantically, I think if the two URLs in question have both parsed successfully, I'd expect resolving one upon the other to always produce a result.

gnprice · 2025-11-22T01:42:52Z

lib/model/store.dart

+  /// Resolve [realmIcon] as a URL relative to [realmUrl].
+  ///
+  /// This returns null if resolving fails.
+  Uri? resolveRealmIconUrl() => _tryResolveUrl(realmUrl, realmIcon);


Seems incongruous to drop the "try" here, as well as to have no "try" in this name while the very similar neighboring method does say "try".

But see my other comment — I think the fix is probably to make this non-nullable.

gnprice · 2025-11-22T01:47:58Z

lib/model/store.dart

+  // The `account` is populated with the `realmIcon` before
+  // PerAccountStore is created, so this should never be null.
+  // See `UpdateMachine.load`.
+  Uri get realmIcon => account.realmIcon!;


Do we ever want to call this getter without resolving the result? Probably not, right?

So that makes this getter a trap for the unwary, when exposed publicly. If we did need the getter in some places, we could address the trap by writing some dartdoc that very clearly says to consider using [resolveRealmIconUrl] instead. But since I think the latter is probably the only call site we actually want… we can do better still by just inlining this into there.

gnprice · 2025-11-22T01:52:18Z

lib/widgets/home.dart

+/// The main-menu sheet.
+///
+/// Figma link:
+///   https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=143-10939&t=s7AS3nEgNgjyqHck-4
+class _MainMenu extends StatelessWidget {


Good idea splitting this out as a widget. I've been thinking we should do that more often for our various showFoo functions — in particular so as to make Flutter's hot reload work for the things they show.

Let's make that split be its own NFC prep commit. That will simplify the diff somewhat for the main commit.

gnprice · 2025-11-22T01:55:19Z

lib/widgets/home.dart

+            AvatarShape(
+              size: 28,
+              borderRadius: 4,
+              child: logo),


nit: let's minimize the number of different names for a given concept:

Suggested change

child: logo),

child: realmIcon),

That way it's clearer to someone looking at this line what this is showing, without having to look around at the rest of this build method's logic.

gnprice · 2025-11-22T01:57:33Z

lib/widgets/home.dart

+class _MainMenuHeader extends StatelessWidget {
+  const _MainMenuHeader();
+
+  void _onPressed(BuildContext context) {


nit:

Suggested change

void _onPressed(BuildContext context) {

void _handleSwitchAccount(BuildContext context) {

Or some other specific name. When it's named just "on pressed", that sounds like it means something that gets called when this whole widget is pressed.

gnprice · 2025-11-22T02:00:28Z

lib/widgets/home.dart

+            return child;
+          },
+          errorBuilder: (_, e, st) {
+            assert(debugLog('$e\n$st')); // TODO(log)


I think this isn't a TODO-log situation — this gets called if the app can't reach the server to fetch the image, and that's probably just the device not having network at the moment, so it's not something we'd want to send to a system like Sentry.

gnprice · 2025-11-22T02:01:42Z

lib/widgets/home.dart

+    final placeholder = ColoredBox(color: designVariables.avatarPlaceholderBg);
+    final logo = realmIconUrl != null
+      ? RealmContentNetworkImage(
+          realmIconUrl,
+          frameBuilder: (_, child, frame, _) {
+            if (frame == null) return placeholder;
+            return child;
+          },


Hmm interesting. What happens if we leave out frameBuilder? Is this piece of logic something we should be putting in AvatarImage?

With the above frameBuilder logic, the placeholder will be displayed while the image is being downloaded, and then be replaced with the downloaded image. Without frameBuilder, the image will pop in when it has completed downloading (though without any funky layout changes as we control the sizing via AvatarShape here).

It could be an improvement for AvatarImage too.

What's the difference between showing the placeholder until the download completes, and having the image pop in when it has completed downloading?

I.e., how does the placeholder look different from what we show without it?

Without placeholder the image pops into the whitespace, see:

no-placeholder.mp4

placeholder.mp4

I see, thanks.

It's not clear to me that that's an improvement. If the images take a second to appear, I feel like having a gray box there, then a transition from that to the icon, is likely to be more conspicuous than a blank space.

Let's leave that logic out from this PR. Similarly errorBuilder — if the icon doesn't load, let's leave its space blank the same way we do for other comparable images like avatars.

gnprice · 2025-11-22T02:02:23Z

lib/widgets/home.dart

+            assert(debugLog('$e\n$st')); // TODO(log)
+            return placeholder;
+          })
+      : placeholder;


nit: put a short fallback like this right next to the error/exception condition that causes it

rajveermalviya · 2025-11-24T19:08:50Z

Thanks for the review @gnprice! Pushed an update, PTAL.

gnprice

Thanks for the revision! Here's comments just on the parts I previously reviewed.

gnprice · 2025-11-25T00:45:47Z

lib/model/store.dart

+  // The `account` is populated with the `realmIcon` before
+  // PerAccountStore is created, so this should never be null.
+  // See `UpdateMachine.load`.
+  Uri get realmIcon => account.realmIcon!;


gnprice · 2025-11-25T00:50:42Z

lib/widgets/home.dart

+    final placeholder = ColoredBox(color: designVariables.avatarPlaceholderBg);
+    final logo = realmIconUrl != null
+      ? RealmContentNetworkImage(
+          realmIconUrl,
+          frameBuilder: (_, child, frame, _) {
+            if (frame == null) return placeholder;
+            return child;
+          },


What's the difference between showing the placeholder until the download completes, and having the image pop in when it has completed downloading?

I.e., how does the placeholder look different from what we show without it?

gnprice · 2025-11-25T00:57:18Z

test/widgets/home_test.dart

+      debugNetworkImageHttpClientProvider = null;
+    });
+
+    testWidgets('_MainMenuHeader', (tester) async {


nit: put before the buttons, since the header appears before the buttons in the code (and also in the UI)

gnprice · 2025-11-25T01:05:14Z

Playing with this a bit, it feels like something of a UX regression to have "switch account" become such a small touch target. That feels like it risks exacerbating the annoyance we've heard from a number of users about it being more annoying than it should to switch between accounts (e.g. #1162).

How about if we make the whole header be the touch target for that? It looks like we changed that in a previous revision because the touch feedback didn't look right (#1937 (comment)); but it should be possible to give it different touch feedback.

chrisbobbe · 2025-12-05T00:19:37Z

I could imagine using the "minimal neutral button small" from the Figma, which our ZulipWebUiKitButton widget already supports:

https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=6092-50794&m=dev

Not pressed	Pressed

alya · 2025-12-05T06:50:58Z

Hm, I don't love that -- I feel like it's drawing attention to an action that for many users wouldn't be super common. We could just label is as "Switch", but I'd prefer to explore @gnprice 's suggestion to make the whole header be the touch target.

rajveermalviya · 2025-12-09T13:59:48Z

Thanks for the review @gnprice! Pushed an update, PTAL.

Also current revision now makes the whole header a touch target. See:

switch-account.mp4

cc @alya @chrisbobbe

gnprice

Thanks for the revision! Just one comment below. I've now read the remaining parts of the commits, too.

gnprice · 2025-12-10T02:15:16Z

lib/widgets/home.dart

+    final placeholder = ColoredBox(color: designVariables.avatarPlaceholderBg);
+    final logo = realmIconUrl != null
+      ? RealmContentNetworkImage(
+          realmIconUrl,
+          frameBuilder: (_, child, frame, _) {
+            if (frame == null) return placeholder;
+            return child;
+          },


I see, thanks.

It's not clear to me that that's an improvement. If the images take a second to appear, I feel like having a gray box there, then a transition from that to the icon, is likely to be more conspicuous than a blank space.

Let's leave that logic out from this PR. Similarly errorBuilder — if the icon doesn't load, let's leave its space blank the same way we do for other comparable images like avatars.

rajveermalviya · 2025-12-10T09:51:35Z

Thanks for the review @gnprice! Pushed an update, PTAL.

Additionally, add a bit of dartdoc for `realmName` and `realmIcon`.

We almost always need the full resolved realm icon URL, so provide a getter that does that.

Fixes: zulip#1037

gnprice · 2025-12-11T17:47:08Z

Thanks! Looks good; merging.

rajveermalviya added the maintainer review PR ready for review by Zulip maintainers label Oct 22, 2025

rajveermalviya assigned chrisbobbe Oct 22, 2025

rajveermalviya requested a review from chrisbobbe October 22, 2025 14:39

chrisbobbe reviewed Oct 24, 2025

View reviewed changes

rajveermalviya force-pushed the pr-org-name-menu branch from 4e5d5f9 to 0d41609 Compare October 28, 2025 15:15

rajveermalviya requested a review from chrisbobbe October 28, 2025 15:21

rajveermalviya force-pushed the pr-org-name-menu branch 2 times, most recently from 1dc1fb7 to c9c67d6 Compare October 28, 2025 19:02

chrisbobbe reviewed Nov 4, 2025

View reviewed changes

rajveermalviya force-pushed the pr-org-name-menu branch from c9c67d6 to f22180b Compare November 10, 2025 19:23

rajveermalviya requested a review from chrisbobbe November 10, 2025 19:24

rajveermalviya force-pushed the pr-org-name-menu branch from f22180b to 13981ab Compare November 13, 2025 15:06

chrisbobbe reviewed Nov 13, 2025

View reviewed changes

rajveermalviya force-pushed the pr-org-name-menu branch from 13981ab to ca099a4 Compare November 14, 2025 08:20

rajveermalviya requested a review from chrisbobbe November 14, 2025 08:20

chimnayajith mentioned this pull request Nov 17, 2025

home: Show org icon in app bar (Inbox, Channels, Direct messages) #1606

Open

chrisbobbe reviewed Nov 19, 2025

View reviewed changes

chrisbobbe requested a review from gnprice November 19, 2025 18:22

chrisbobbe removed their assignment Nov 19, 2025

chrisbobbe added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Nov 19, 2025

rajveermalviya force-pushed the pr-org-name-menu branch from ca099a4 to 2617eba Compare November 19, 2025 18:38

gnprice reviewed Nov 22, 2025

View reviewed changes

rajveermalviya force-pushed the pr-org-name-menu branch 3 times, most recently from ea2d43d to 0444640 Compare November 24, 2025 18:44

rajveermalviya requested a review from gnprice November 24, 2025 19:08

gnprice reviewed Nov 25, 2025

View reviewed changes

rajveermalviya force-pushed the pr-org-name-menu branch from 0444640 to 6460549 Compare December 4, 2025 18:00

rajveermalviya force-pushed the pr-org-name-menu branch from 6460549 to d9beb1a Compare December 9, 2025 13:55

gnprice reviewed Dec 10, 2025

View reviewed changes

rajveermalviya force-pushed the pr-org-name-menu branch from d9beb1a to 8abf61c Compare December 10, 2025 09:50

rajveermalviya requested a review from gnprice December 10, 2025 09:51

rajveermalviya mentioned this pull request Dec 11, 2025

share: Support switching accounts #1883

Open

rajveermalviya added 5 commits December 11, 2025 09:46

store: Make realmName and realmIcon getters non-nullable

f1aa5b6

Additionally, add a bit of dartdoc for `realmName` and `realmIcon`.

store: Replace realmIcon getter with resolvedRealmIcon

de4b28a

We almost always need the full resolved realm icon URL, so provide a getter that does that.

button: Give ZulipIconButton an optional tooltip param

c478ac3

home [nfc]: Factor out _MainMenu widget

36e4d41

home: Show current organization's name and logo atop main menu

603edcd

Fixes: zulip#1037

gnprice force-pushed the pr-org-name-menu branch from 8abf61c to 603edcd Compare December 11, 2025 17:47

gnprice merged commit 603edcd into zulip:main Dec 11, 2025

		? RealmContentNetworkImage(realmIconUrl)
		: const SizedBox.shrink()),

	void _onPressed(BuildContext context) {
	void _handleSwitchAccount(BuildContext context) {

Show current organization's name and logo atop main menu #1937

Show current organization's name and logo atop main menu #1937

Uh oh!

Conversation

rajveermalviya commented Oct 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alya commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rajveermalviya commented Oct 23, 2025

Uh oh!

alya commented Oct 23, 2025

Uh oh!

alya commented Oct 23, 2025

Uh oh!

chrisbobbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rajveermalviya commented Oct 28, 2025

Uh oh!

alya commented Oct 28, 2025

Uh oh!

chrisbobbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rajveermalviya commented Nov 10, 2025

Uh oh!

chrisbobbe commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alya commented Nov 10, 2025

Uh oh!

rajveermalviya commented Nov 13, 2025

Uh oh!

chrisbobbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rajveermalviya commented Nov 14, 2025

Uh oh!

rajveermalviya commented Oct 22, 2025 •

edited

Loading

alya commented Oct 23, 2025 •

edited

Loading

chrisbobbe commented Nov 10, 2025 •

edited

Loading