Use native windows for dialogs

mentioned in merge request !105 (merged)

Also quoting @seb from !105 (comment 60867):

I was (and am) having trouble having this scrollable and work with a flexible, minimum size, which is why I went with these 80% of full size. Maybe the compose people have the same problem with scrollable content in AlertDialogs. It seem like when I add the VerticalScrollbar the LazyColumn and the Scrollbar both use fill the maximum size, no matter what I do.

You're right, we could make this non-scrollable at the moment. I think I'm just anticipating that we'll be requiring scrolling soon when the content grows a little longer. Certainly it will be required if we add a tab with the license text or with a list of third party libraries. That's why I went with a scrollable solution right away (sure the preview scenario is not representing our production setting with the minimum size of the parent window of 800x600, but there I also used the scrollbars already)

One potential advantage: the AddContactDialog would not close when (accidentally) clicking outside of it. This happened several times during the UX coaching.

changed milestone to %Desktop 0.2.0

+1 to this, I have run into many annoying sizing issues with using the Compose Dialog composable for the AddContactDialog screen. I think the included AlertDialog is just not intended to be used for larger sized dialog forms.

Should I refactor my current working branch for the AddContactDialog UI update to use the window api?

I'd say it depends on how difficult such a refactor would be. I think we should decide at some point whether we want a global kind of "window manager" at the root of the UI tree that manages all open windows in a standard way and it might be easier to change to the window API after that potential design change. So if you've already managed to get the UI working with the Dialog solution, I would keep it as such and move to the window API in a separate step.

I'm not sure we should let the general refactoring of dialogs block the improvements to and refactoring of the AddContactDialog. Maybe even in the contrary. If I'm not mistaken, we all think we should probably rather use a native window for the AddContactDialog than the AlertDialog. If we don't replace all our AlertDialog with native dialogs (which I'm not sure of, but maybe we won't), we'll end up with a mixture of native Dialogs and AlertDialogs. So the general solution for window management will need to take that into account. And doing that will probably be easier if we already have both kinds of dialogs somewhere in the app instead of doing this on a hypothetical basis.

Also I'm not sure the global window manager will really need to deal with all dialogs or maybe only some of them. In terms of encapsulation it would maybe still be good if the screens can produce their own dialogs. I think this topic came up when I was working on the various errors that can occur when using the AddContactDialog and was mainly about error dialogs. I don't remember all the specifics, but I kept the branch around where I added this ErrorManager class: (https://code.briarproject.org/briar/briar-desktop/-/tree/81-error-manager).

I came across the basic Dialog() composable which spawns a new window and disables the parent window until the dialog is closed. When you set the undecorated property to true it gives you similar behavior to the AlertDialog without the layout issues. Here's the AddContactDialog running inside one of these undecorated dialogs:

looks good. Just the padding of the window seems to be smaller than with AlertDialog

I can fully control all the padding and window size using a DialogState parameter that is provided, in that demo I went with a width of 375.dp to see how it would look on mobile-width screens.

e.g. for the AddContactDialog and AboutDialog, which do not strictly require to be modal.

Just looking into compose's dialog and window management. Small detail: Dialog is also modal. So I guess with native windows, we can still have modal and non-modal dialogs. If we want a modal dialog we should use Dialog and if we want a non-modal dialog we should use Window.

I'm not sure mode/non-modal is the key point for deciding on native windows.

I think the bigger problem with non-native windows (i.e. AlertDialogs) is that they seem to be limited in what we can do inside them.

We could try to overcome those limitations with our own implementation of dialogs, similar to AlertDialogs.

The upside of native windows is that they don't have the drawbacks above.

I think the downside of native windows is probably that it's not clear how well those are going to work on mobile devices such as the Librem.

changed milestone to %Desktop 0.4.0

AddContactDialog is now a native Window with !144 (merged). We could still discuss if we want the native system's window decoration for those dialogs (we currently have).

mentioned in merge request !144 (merged)

mentioned in merge request !177 (merged)

Another issue we should tackle is in the dialog for changing password

see !177 (comment 63494)

Switching to native windows would solve the issues with non-accessible dialogs and error messages for screen reader users we faced during #366.

mentioned in merge request !245 (merged)

changed milestone to %Desktop 1.0.0

Use native windows for dialogs

Designs

Child items ...

Activity