Add region management#379
Conversation
This adds region management: the user can manage a list of available regions and for each channel pick a region from that list to apply to messages. Region discovery from nearby repeaters will be done in a separate PR. This is a part of the work needed for zjs81#120.
| // TODO(clauwn): add community handling | ||
| final isCommunityChannel = false; | ||
| final isCommunityPublic = false; | ||
|
|
||
| if (isCommunityChannel) { | ||
| iconColor = Colors.purple; | ||
| bgColor = Colors.purple.withValues(alpha: 0.2); | ||
| icon = isCommunityPublic ? Icons.groups : Icons.tag; | ||
| } else if (widget.channel.isPublicChannel) { | ||
| icon = Icons.public; | ||
| iconColor = Colors.green; | ||
| bgColor = Colors.green.withValues(alpha: 0.2); | ||
| } else if (widget.channel.isHashtagChannel) { | ||
| icon = Icons.tag; | ||
| } |
There was a problem hiding this comment.
This is code from lib/screens/channels_screen.dart, which includes handling for the community channels. How do we want to manage this, other than duplicating it?
There was a problem hiding this comment.
Probably just a helper instead of duplicating
There was a problem hiding this comment.
I'm mostly talking about the relationships that are kept in a data structure in the channels screen. It's the part that i mentioned a relational database could be nice for
|
Looks good so far. Tested and working as expected. I think for now just move that community channel stuff into a shared helper until we get into a better database for storage where we can have relationships. Or start storing a bool for community channels in the normal community model and storage. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e074fd806
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| expectsGenericAck: true, | ||
| ); | ||
| } finally { | ||
| await sendFrame(buildSetFloodScopeFrame('')); |
There was a problem hiding this comment.
Avoid consuming message ACKs with flood-scope reset
When a channel message is sent, sendFrame(..., expectsGenericAck: true) queues the message ACK, but this finally immediately sends another command that can also produce RESP_CODE_OK/RESP_CODE_ERR and is not tracked separately. If the flood-scope reset response arrives before the channel-send response, _handleOk/_handleErrorFrame will pop the pending channel message entry, marking it sent or clearing it based on the reset ACK rather than the actual message result; this is especially likely on scoped sends or older firmware that responds to the new command with an error. The flood-scope commands need to be serialized/acknowledged without sharing the channel-message ACK queue, or the reset should not run while a channel send ACK is pending.
Useful? React with 👍 / 👎.
|
Hello! @stphnrdmr could you please let me know if there are any updates regarding the regions? |
|
Hi @HDDen, all current progress is pushed to this branch. Feel free to continue this feature based on it, but let me know if you do so we can avoid doing the work twice. |
Okay, if you don't plan on making any changes in the ~next week +/-, I'd try to finish up the feature. Only question: I'm using the latest version of flutter, so I feel like we're going to run into incompatibilities. Can I clone your branch and re-release the result as a new PR? |
This adds region management: the user can manage a list of available regions and for each channel pick a region from that list to apply to messages.
Region discovery from nearby repeaters will be done in a separate PR.
This is a part of the work needed for #120.