Deltachat-desktop: Remove Go Back menu item?

[ralphtheninja]

Currently, when the menu item is selected it does windows.main.dispatch('escapeBack') but nothing is handling that, afaik. (Also not sure what's the difference between windows.main.send('foo') and windows.main.dispatch('foo'))

[r10s]

it could have the same functionality as the "back button" that brings you eg. from the chat view to the chat list.
if the "escape" key also works, i would leave it; these soft of menu entries are useful for a simple lookup of shortcuts imho.

[Jikstra]

I would stop switching screens and start opening dialogs. Besides maybe for login. We can put everything in a overlay dialog on display it on top of the the SplittedChatListAndView Component. It's what most desktop chat applications do.

Especially as we can't really fill a whole screen with all the stuff in edit group... it all would fit in a dialog without a problem.

[hpk42]

On Mon, Oct 22, 2018 at 10:03 -0700, Jikstra wrote:

I would stop switching screens and start opening dialogs. Besides maybe for login. We can put everything in a overlay dialog on display it on top of the the SplittedChatListAndView Component. It's what most desktop chat applications do.

Especially as we can't really fill a whole screen with all the stuff in edit group... it all would fit in a dialog without a problem.

+1

[okdistribute]

That go back button is likely a holdover from WebTorrent. Not necessarily the way we would do it here, or useful in our context. I would recommend we just remove that button and direct the user to hit “cancel” or other clearly marked navigation buttons to get around the app.

The ScreenController basically already handles the underlying windows. Refactoring to use dialogs wouldn’t necessarily make it easier to manage this particular bug, and would also likely complicate the React lifecycle. I think it would be a chunk of work that isn’t necessary to do at the moment.

[okdistribute]

Also from a UX perspective, dialogs should be used only when asking the user for specific input or output, or notifying them of something (like progress). It removes parts of the screen from usable display space

[r10s]

i think edit-groups, create-groups, settings and so on _can_ go to a dialog. i think this is fine from a UX perspective as input is requested from the user. i also think this is also quite normal in desktop apps (not always in webapps).

but if this would make things too complicated, i would also be fine without dialogs. eg. assume edit-group-dialog lying over chat-view-window - added members should update the number of members in the chatview then. probably not that hard, as everything is event-driven, but maybe sth. to keep in mind.

[Jikstra]

Refactoring to use dialogs wouldn’t necessarily make it easier to manage this particular bug, and would also likely complicate the React lifecycle.

Good point, don't know much about how we handle dialogs yet, but i guess this should be managable. Besides that on most dialogs we don't really have to rerender (for the beginning9 if not some action happend inside the dialog. But this could be a problem at some point.

Also from a UX perspective, dialogs should be used only when asking the user for specific input or output, or notifying them of something (like progress). It removes parts of the screen from usable display space

I agree in general, but for the most things we would display in a dialog, a whole screen is too much. The edit groups/create group screens totally fail at filling the window in a useful way. We would need to center things or something else which again would be unused space. Also I really like that the the SplittedChatListAndView would be seeable the whole time, even if it's a little blurred.
Dialogs we could use for:

• About
• Settings
• Key Exchange (we are currently already doing this)
• Group Edits
• Create Chat/Croup...

But of course, the logic in a dialog would be more complex. Especially because we would need a seperate screen controller for dialogs at some point.

@ralphtheninja can we somehow split this issue in a new issue about dialogs?

[ralphtheninja]

@ralphtheninja can we somehow split this issue in a new issue about dialogs?

Please just create new issues. This issue was about removing a single menu item and turned into a completely different discussion imo :smile: