briar issueshttps://code.briarproject.org/groups/briar/-/issues2021-12-06T14:25:33Zhttps://code.briarproject.org/briar/briar-desktop/-/issues/77Make it possible to run multiple versions of briar-desktop concurrently2021-12-06T14:25:33ZSebastianMake it possible to run multiple versions of briar-desktop concurrentlyFor interactive testing it is extremely useful to be able to start multiple UIs simultaneously and interact with them. A separate data directory can be specified already, the only thing preventing this is the hardcoded tor port (no two a...For interactive testing it is extremely useful to be able to start multiple UIs simultaneously and interact with them. A separate data directory can be specified already, the only thing preventing this is the hardcoded tor port (no two apps can listen on the same port). Let's see if we can make the Tor port configurable in upstream briar. I already solved this for [briar-swing here](https://code.briarproject.org/sebkur/briar-swing/-/commit/baa4d22d4011ee9b570301435a71d266ebcf11ab). It could be done that way, or a bit differently, but I think making the tor port configurable is something useful.Desktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/61Set up internationalization framework2021-12-06T14:25:34ZNicoSet up internationalization frameworkIt seems like there is no direct support for translations in Compose for Desktop: [JetBrains/compose-jb#425](https://github.com/JetBrains/compose-jb/issues/425)
Jetpack Compose on Android uses the already known _strings.xml_, but this d...It seems like there is no direct support for translations in Compose for Desktop: [JetBrains/compose-jb#425](https://github.com/JetBrains/compose-jb/issues/425)
Jetpack Compose on Android uses the already known _strings.xml_, but this doesn't work on the desktop.
In that issue they mentioned the following framework that allows using resources across various platforms: [icerockdev/moko-resources](https://github.com/icerockdev/moko-resources)
Once set up, we should import the translations from Briar GTK: https://code.briarproject.org/briar/briar-desktop/-/issues/4Desktop 0.1.0NicoNicohttps://code.briarproject.org/briar/briar-desktop/-/issues/477Second login attempt after failed startup results in infinite loading screen2023-02-24T13:50:45ZMikolai GütschowSecond login attempt after failed startup results in infinite loading screenExperienced with the known database migration issue and version 0.4.0 on an old database.
The error screen is correctly shown, but allows to go back:
![image](/uploads/205466faf066bf4afc031ccca4d12137/image.png)
After entering the pas...Experienced with the known database migration issue and version 0.4.0 on an old database.
The error screen is correctly shown, but allows to go back:
![image](/uploads/205466faf066bf4afc031ccca4d12137/image.png)
After entering the password again, the loading screen stays forever and logs show:
```
14:44:19.987 [pool-1-thread-1] WARN o.b.b.desktop.login.StartupViewModel - Startup failed: SERVICE_ERROR
14:45:05.036 [pool-1-thread-1] WARN o.b.b.lifecycle.LifecycleManagerImpl - Already running
14:45:05.037 [pool-1-thread-1] INFO o.b.b.desktop.login.StartupViewModel - Already running
```Desktop 0.4.1SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/300Include Briar core version in about dialog2022-02-17T13:33:07ZNicoInclude Briar core version in about dialoghttps://code.briarproject.org/briar/briar-desktop/-/merge_requests/150#note_62623https://code.briarproject.org/briar/briar-desktop/-/merge_requests/150#note_62623Desktop 0.2.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/214It's possible to add one's own briar:// links when appending one or multiple ...2022-01-18T16:18:52ZSebastianIt's possible to add one's own briar:// links when appending one or multiple charsWhen checking wheter the user-provided link is our own link, we use the whole string and compare that to our own link while we really should only compare the valid part found by `HandshakeLinkConstants.LINK_REGEX.matcher(link).find()`When checking wheter the user-provided link is our own link, we use the whole string and compare that to our own link while we really should only compare the valid part found by `HandshakeLinkConstants.LINK_REGEX.matcher(link).find()`Desktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/199Show different placeholder screen if pending contact is selected2022-01-12T11:32:46ZMikolai GütschowShow different placeholder screen if pending contact is selectedCurrently, it looks like the following. It would be best to display some information about what it means for a contact to be pending.
![image](/uploads/451a4a64648af2face680c6ef6330253/image.png)Currently, it looks like the following. It would be best to display some information about what it means for a contact to be pending.
![image](/uploads/451a4a64648af2face680c6ef6330253/image.png)Desktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/99Avoid passing individual view models around2022-01-07T21:51:07ZMikolai GütschowAvoid passing individual view models aroundFor now, all view models are injected by Dagger at the start of the application in the top composable and then passed to the individual composable functions that actually need it. This has several disadvantages:
- the composables further...For now, all view models are injected by Dagger at the start of the application in the top composable and then passed to the individual composable functions that actually need it. This has several disadvantages:
- the composables further up the tree have a lot of view models as parameters that are just passed down to other composables that actually need it. Also, adding a new view model adds a new function parameter to all composables up to the root resulting in a lot of unnecessary changes.
- all view models are initialized when the application starts and also start to listen for events, even if the respective screen is not shown (yet)
- there can always only be a single instance of a certain view model (unless we initialize two or more of them in the top composable). That would forbid us to support displaying several chats at the same time in separate windows (the Pidgin (?) way of doing things). That one might not be a big deal, though.
I would propose the following:
- implement a `ViewModelProvider` similar to the one available in Android that could either hold all view models from the application start on (not resolving the third point) or instantiating them on demand
- have a base `ViewModel` class/interface that provides the methods `onInit()` and `onCleared()` where such things as adding/removing the view model from the `eventBus` can be done
- adopt the convention of only instantiating view models within composables called `Screen` (e.g. `MainScreen` for the view model handling the global state, `PrivateMessageScreen` for the contact list view model) and always provide a second composable with the same name that takes the view model as a parameter (allowing for easier testability). The view model should always be instantiated as down in the UI tree as possible and as up in the tree as necessary. `Screen`s could be seen as analog to `Fragment` or `Activity` in the Android world.
- implement a helper composable function called `Screen` that takes a view model class name and does the repetitive process of obtaining the view model from the provider, call `onInit()` and `onCleared()` when appropiate (the compose `DisposableEffect` will come to handy here). Additionally, `Screen` would take a composable function where the view model is available (similar to the `ApplicationScope` that exposes `exitApplication` and is available after `runApplication`).
As a rough sketch, the usage might then look like the following:
```kotlin
@Composable
fun PrivateMessageScreen() = Screen(ContactListViewModel::class) {
PrivateMessageScreen(viewModel)
}
@Composable
fun PrivateMessageScreen(viewModel: ContactListViewModel) {
// actual content using the viewModel
}
```Desktop 0.1.0Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-desktop/-/issues/95Implement view model for private chat view2021-12-06T14:25:10ZMikolai GütschowImplement view model for private chat viewDesktop 0.1.0Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-desktop/-/issues/90Move Briar API calls from @Composables to view models2021-12-06T14:25:10ZMikolai GütschowMove Briar API calls from @Composables to view modelsAs soon as no calls are left, we can remove the `CompositionLocalProvider` and (most of) the `*Manager` injections in `BriarUi`.
This is a follow up of !30 and #78 .As soon as no calls are left, we can remove the `CompositionLocalProvider` and (most of) the `*Manager` injections in `BriarUi`.
This is a follow up of !30 and #78 .Desktop 0.1.0Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-desktop/-/issues/87Handle long names in contact list2022-01-11T22:26:24ZMikolai GütschowHandle long names in contact listWhile testing !22 I found this visual glitch for (the actually not so long name) *Joseph Louis Lagrange*:
![image](/uploads/f2e7835605a58050bffd3368a734cdf2/image.png)
We should decide on how this should be handled:
- Should the name be...While testing !22 I found this visual glitch for (the actually not so long name) *Joseph Louis Lagrange*:
![image](/uploads/f2e7835605a58050bffd3368a734cdf2/image.png)
We should decide on how this should be handled:
- Should the name be cut after a given amount of characters to something like *Joseph Louis Lagr...*?
- Should we wrap the name to a second line? (I remember we were advised not to do so in the UX coaching)
- Would we like the name to be shown in a scrolling fashion (like a ticker)?Desktop 0.1.0NicoNicohttps://code.briarproject.org/briar/briar-desktop/-/issues/82Warn users of potential attack when creating contacts2022-01-20T13:18:02ZNicoWarn users of potential attack when creating contacts@grote or @akwizgran informed me of this potential attack back in the old days of Briar GTK. An attacker might try to find out which contacts a user has, which we try to prevent by implementing the following logic from the Android client...@grote or @akwizgran informed me of this potential attack back in the old days of Briar GTK. An attacker might try to find out which contacts a user has, which we try to prevent by implementing the following logic from the Android client:
https://code.briarproject.org/briar/briar/-/blob/beta-1.2.14/briar-android/src/main/java/org/briarproject/briar/android/contact/add/remote/NicknameFragment.java#L139
Also see the respective MR at Briar GTK https://code.briarproject.org/briar/briar-gtk/-/merge_requests/97 where I tried to re-implement it, but we should follow the Android's logic because that one got peer reviewed.
Sub task of https://code.briarproject.org/briar/briar-desktop/-/issues/81.
Follow up to https://code.briarproject.org/briar/briar-desktop/-/merge_requests/28.Desktop 0.1.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/12Private groups2023-06-26T13:29:11ZMikolai GütschowPrivate groupsDesktop 0.5.0Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-desktop/-/issues/523Feature request: mark as un/read button2023-06-17T20:28:59ZAminda SuomalainenFeature request: mark as un/read buttonCurrently the only way to mark something as read is to stare for it for a moment and then scroll down and wait a moment again. This takes a long time especially when there are many unreads in a forum and feels annoying when I have alread...Currently the only way to mark something as read is to stare for it for a moment and then scroll down and wait a moment again. This takes a long time especially when there are many unreads in a forum and feels annoying when I have already read the forums on another device. Thus I would like there to be buttons to:
* [ ] mark chat as read
* [ ] mark chat as unread, in case there is something I would like to return to later and have the UI remind me of it with the unread marker.Desktop 0.5.0Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-desktop/-/issues/515Mailbox Error Dialog: when unpairing is successful, don't show "error" as title2023-04-26T08:00:43ZSebastianMailbox Error Dialog: when unpairing is successful, don't show "error" as titleI think it is rather confusing when this says "error" in this case. It's actually rather a success dialog.I think it is rather confusing when this says "error" in this case. It's actually rather a success dialog.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-mailbox/-/issues/189BindException when debug and release versions are running at the same time2023-03-07T12:55:40ZakwizgranBindException when debug and release versions are running at the same time```
2023-02-14 13:46:49.069 13109-13109 o.b.m.a.StatusManager org.briarproject.mailbox.debug I [main] state: StartedSettingUp
2023-02-14 13:46:49.166 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [T...```
2023-02-14 13:46:49.069 13109-13109 o.b.m.a.StatusManager org.briarproject.mailbox.debug I [main] state: StartedSettingUp
2023-02-14 13:46:49.166 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:49.210 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:49.309 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:49.459 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:50.103 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:50.103 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:50.211 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:51.757 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:53.896 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:55.160 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:56.460 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:46:57.786 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:47:00.449 13109-13191 o.b.m.c.t....tTorPlugin org.briarproject.mailbox.debug I [Thread-6] V3 descriptor uploaded
2023-02-14 13:47:30.228 13109-13176 o.b.m.c.s....leWakeLock org.briarproject.mailbox.debug I [pool-1-thread-1] Renewing wake lock org.briarproject.mailbox.debug
2023-02-14 13:47:30.229 13109-13176 o.b.m.c.s....leWakeLock org.briarproject.mailbox.debug V [pool-1-thread-1] Wake lock org.briarproject.mailbox.debug has 2 holders
2023-02-14 13:48:30.242 13109-13176 o.b.m.c.s....leWakeLock org.briarproject.mailbox.debug I [pool-1-thread-1] Renewing wake lock org.briarproject.mailbox.debug
2023-02-14 13:48:30.243 13109-13176 o.b.m.c.s....leWakeLock org.briarproject.mailbox.debug V [pool-1-thread-1] Wake lock org.briarproject.mailbox.debug has 2 holders
2023-02-14 13:49:23.338 14060-14108 AndroidRuntime pid-14060 E FATAL EXCEPTION: AndroidExecutor
Process: org.briarproject.mailbox, PID: 14060
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:454)
at sun.nio.ch.Net.bind(Net.java:446)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:32)
at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:114)
at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:3)
at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:40)
at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:5)
at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:15)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:17)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:204)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:35)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:11)
at io.ktor.server.netty.EventLoopGroupProxy$Companion$$ExternalSyntheticLambda1.run(R8$$SyntheticClass:20)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:3)
at java.lang.Thread.run(Thread.java:761)
2023-02-14 13:49:23.342 1274-3841 ActivityManager pid-1274 E App crashed! Process: org.briarproject.mailbox
at java.lang.Thread.run(Thread.java:761)
```
It looks like this is thrown after the hidden service has been published, so it's not the Tor port that's causing the conflict.Mailbox: ReleaseTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-desktop/-/issues/484Implement mailbox troubleshooting wizard2023-04-26T07:54:47ZTorsten GroteImplement mailbox troubleshooting wizardTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-desktop/-/issues/483Implement mailbox problem notification2023-03-16T16:59:15ZTorsten GroteImplement mailbox problem notificationWhen the mailbox couldn't be reached for some time (`MailboxProblemEvent`), we need to get the user's attention.When the mailbox couldn't be reached for some time (`MailboxProblemEvent`), we need to get the user's attention.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-mailbox/-/issues/187Add cancel button in STARTING state2023-03-13T14:23:03ZTorsten GroteAdd cancel button in STARTING stateTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-mailbox/-/issues/186Add support for Snowflake2023-03-29T13:41:38ZakwizgranAdd support for SnowflakeTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar-desktop/-/issues/456Consistent naming "Briar" throughout app2023-02-05T22:26:35ZMikolai GütschowConsistent naming "Briar" throughout appThe following discussion from !274 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/274#note_73755): (+3 comments)
> While trying out the installer gener...The following discussion from !274 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/274#note_73755): (+3 comments)
> While trying out the installer generated by the CI, I noticed we use "Briar" as the application name during installation and also for the `.desktop` file for Linux, but the title of the main window is "Briar Desktop". Not sure if we should instead be consistent.
TL;DR: We probably want to use "Briar" everywhere instead of "Briar Desktop".Desktop 0.4.1SebastianSebastian