Add switch button Icon #1

AshutoshKhadse23 · 2024-12-21T21:37:20Z

Here I add also added the switch account button and placed at single location with my profile.
Like provide in the image

Related zulip#1178

The icon is taken from Zulip web: https://github.com/zulip/zulip/blob/74d7f1192/web/shared/icons/info.svg Because there were no suitable icon in the Icons page of the Figma design: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=544-22131&p=f

Fixes: #1128

I've just filed this TODO item as #1201, so link there.

This method has gotten awfully long and tangly. Here's a first step on giving it some more organized structure.

This logic pairs closely with _maybeReportToUserTransientError, so pulling it out lets that logic live nearer each other.

This is basically a form of error reporting.

Now the `poll` method itself is a lot more focused on the overall structure of how polling works.

This takes it a bit farther in squeezing out details that aren't part of the main picture of what this method is doing. At this point the main remaining thing that feels like clutter is all the `if (_disposed) return;` lines. But I don't have any ideas at the moment for a better way to handle those.

Xcode made the project.pbxproj changes when I changed the "macOS Deployment Target" setting in the GUI from 10.14 to 10.15 and back again. The Runner.xcscheme changes happened when I built the app to run. A quick test confirmed that 7649477 explains the change from "zulip.app" to "Zulip.app" (I tried a different string "asdfjkl" and saw that it propagated in the same way). Not sure what explains removing the "name = Pods;" line, but there's a "path = Pods;" line right under it, and anyway the app continues to build.

…m ios/ We brought this to ios/Podfile from zulip-mobile in a7ed31e; helpful to have it on the macOS side too.

Fixes #1116. Done by changing the line in the Podfile, and following the (recently added) comment there by changing a setting in the Xcode GUI. The Podfile change seems to be the only thing missing when Greg attempted this bump: (from #1116) > Naturally we're happy to bump up our minimum macOS deployment > target — 10.15 is from 2019, and even increasing to last year's > macOS 14 would be perfectly fine. But I spent a few minutes just > now attempting to do so — editing the `MACOSX_DEPLOYMENT_TARGET = > 10.14;` lines in the `project.pbxproj` file so they say 10.15 (or > 13.0) instead, then also tried setting it in Xcode which added > some new lines of that form — and the error persisted. (Perhaps > there's somewhere *else* that `pod update` is looking? Perhaps it > has a cache of some kind that it fails to update?)

As Greg said in #1116: > 10.15 is from 2019, and even increasing to last year's macOS 14 > would be perfectly fine.

Related: #1204

And update Flutter's supporting libraries to match.

Done with: flutter pub upgrade --major-versions share_plus{,_platform_interface} (then commit, for the sake of a no-uncommitted-files check) tools/upgrade pub (then squash) See discussion: https://chat.zulip.org/#narrow/channel/243-mobile-team/topic/deps.3A.20running.20.60tools.2Fupgrade.20pub.60.20twice/near/2013483 All the Firebase packages are now upgraded to latest; none of them appear in the `flutter pub outdated` list. This seems to have unlocked upgrading `drift` too. Some followups were needed: - ran `tools/check drift --all --fix` - ran `tools/check build_runner --all --fix` - followed an instruction from the analyzer: info • 'package:drift_dev/api/migrations.dart' is deprecated and shouldn't be used. Import `package:drift/migrations_native.dart` instead • test/model/database_test.dart:4:1 • deprecated_member_use Greg pointed out that it's awkward that some Drift files change, but he found that they're not substantive changes, so it's fine: #1184 (comment) #1184 (comment)

Related: #1219

Starting with our last Flutter update 273674f (#1184), a directory android/app/.cxx/ gets created whenever building or running the app for Android. It has a lot of generated files in it. See chat discussion: https://chat.zulip.org/#narrow/channel/516-mobile-dev-help/topic/Error.20in.20running.20the.20app/near/2017805 https://chat.zulip.org/#narrow/channel/516-mobile-dev-help/topic/.2Ecxx.2F.20files.20created/near/2017819 There's an upstream issue for the need to add a gitignore line for these in the `flutter create` templates: flutter/flutter#160372 Even when that's done, it won't affect existing apps like ours; we need to make a similar update in our own tree. That's this commit.

We always know the current visibility policy, so we can pass that unconditionally.

This makes it a bit more transparent what each of these cases is doing, by having fewer local abstractions with their own names.

Seeing a condition like `channelMuted != null`, it's not entirely clear what it means for a "channel muted" value to be null. We can express the point more directly as `subscription != null`, and then consult `isMuted` on the subscription.

This change makes the message list's topic headers case-insensitive Messages with topics differing only in case (e.g., "missing string" and "Missing string") will now share a single header. This aligns the behavior with Zulip web and ensures a consistent user experience. Fixes: #739

chrisbobbe · 2025-01-02T21:56:49Z

It looks like you've made a PR in the wrong direction; you want the destination to be main on https://github.com/zulip/zulip-flutter not your fork.

@chrisbobbe

Skips the test that fails because of the platform specific path separator being '\' instead of '/ on Windows. Read this excellent explanation by @chrisbobbe for better understanding: https://chat.zulip.org/#narrow/channel/516-mobile-dev-help/topic/failing.20composebox.20test.20while.20running.20check.20script/near/2000301 [greg: rewrote comment]

We don't expect UpdateMessageEvent to signal a change in a message's read state; that's what UpdateMessageFlagsEvent is for. Our unreads model does process `UpdateMessageEvent`s, though, to apply changes in a message's mentioned state. Also, we expect the client to be synced with the server for all messages' read state, assuming !oldUnreadsMissing. Where we process `UpdateMessageEvent`s, we have a `debugLog` line to alert us if one of these expectations isn't being met. It's been giving false positives when we get an UpdateMessageEvent for a bulk message move where some of the moved messages are read and some aren't. Since the server only intends the event's `flags` to apply to the event's `messageId` (one message), we should only be checking that message, not all the messages in the event's `messageIds`. From the API doc on `flags`: https://zulip.com/api/get-events#update_message > The user's personal message flags for the message with ID > message_id following the edit.

And make it public, with dartdoc and tests, while we're at it.

For this debug check to work, it just needs a known read state for one message. When `oldUnreadsMissing` is false (the common case), the model holds one of two answers for a message's read state: known-unread or known-read. When `oldUnreadsMissing` is true, the model holds known-unread or unknown. Before, we were skipping the debug check on seeing that `oldUnreadsMissing` is true. That's earlier than we need to abort, because the model might still hold a known-unread state for the message. Now, we go ahead with the debug check if that's the case, and still skip it otherwise. Done by using our new `isUnread` helper, in this separate commit because it's not NFC in debug mode.

…ssage` When we add the resolve/unresolve button, coming up, we'll use this to test the edge case where the button isn't shown in the message-list app bar if the message list is empty. (For that case we'll just pass an empty Iterable for this.)

…entHeader Move _containsDifferentChannels method to StreamMessageRecipientHeader where it's used, and pass narrow directly instead of a pre-computed showStream boolean.

…able. Fixes: #1171

This covers some of the fields that can be inconsistent (`zulipFeatureLevel` in particular) when a test is not set up properly Signed-off-by: Zixuan James Li <zixuan@zulip.com>