New chat history UI

[CoBC]

Hi,
in the PR #2310, I changed the UI of chat history.
Currently, TT use a readonly editbox to display chat history in main window and private text message dialog.
I suggest to switch to a list containing all history.

Advantages of a list

• Uniformization: majority of chat apps use list for history, only web based apps (with Electron for example) use navigable content, but it's due to the webpage UI
• Accessibility: readonly editbox have a lot of accessibility issues, especially for Windows users with screenreader, E.G. if a message contains multiple lines, blank lines are not announced and previous line is repeated again and again when navigating.
• Links support: in the readonly editbox, you have to scroll with arrow keys to place focus in a link and than press enter to open link, with the list, pressing enter on a message will open the link (if message contains only one link) or show a menu with all available links to choose the link to open
• Ability to delete only some history items: with readonly editbox, you can't delete an item from the history, you have to keep entire history or clear it entirely, with the list, an ability to delete only one item is possible
• Ability to show more content for a message: we can, for example, imagine an user who don't show date and time for a message, with the list, we can add the ability to display detailed content for a message in a dialog box, and show more info like date and time

Inconvenients of the list

The only inconvenient I see for the list is the unability to select piece of text for a message and than copy this text part, but, this can be solved by adding a dialog to show message details, in this dialog we'll show message content in a readonly editbox and text will be selectable. However I'm not sure select only a piece of text is the most commonly usage of the chat history.

I think we should do what users want, so votes are open, I suggest to keep this pool open E.G. until the week-end and than make a decision regarding PR #2310

[valiant8086]

an't figure out how to test the new lists, I guess I'd have to run from source or something. But we should

1. account for the issue sighted users will have with the mouse. @bear101 had already mentioned that there's an issue selecting the content with a mouse. Need to ensure the list works properly with mouse, messages should be selectable by holding down right mouse button while dragging the pointer among list items, or the user needs be able to hold ctrl and left single click list items. Just right clicking an item should do the same thing context key does, giving a list of actions for the item. Double clicking the list item should open the link if it has one or the links list if it has multiple links.
2. consider making the list support multi select by holding ctrl and using up and down arrow, with space to toggle, just like explorer.
3. consider implementing ctrl+c to directly copy the selected list item or list items. If copying list items, it should put them in some format that will be usable when pasted elsewhere.
4. ensure context key and right click open menu of options for selected messages. Perhaps including links list and copy messages.
5. ensure scrolling works as intended with mice or touch pads
6. check that keyboard navigation works as intended, make sure home and end work, and possibly get page up and page down to do something.
7. possibly enable colum modifying, and ensure accessibility of that for screen readers as well. Rearanging columns could allow date to be on the left of the message as sighted would probably prefer, but screen reader users would want it on the right of messages.
8. ensure long messages are reading properly. Certain apps have trouble with long messages not wanting to read entirely in list views. If they don't read entirely, a screen reader user will want something to happen to note this message is not all going to be read if you sit and listen to it. Perhaps the list item needs to say something at the beginning if it is truncated.
9. can implement space bar or left single click on focused list item to open a read only edit box showing entire message

[CoBC]

You can test the list by running this build:
https://github.com/BearWare/TeamTalk5/actions/runs/9230038697/artifacts/1536450018
Note, however the following: as this build was produced by GitHub CI, WebRTC is not included, so in this build denoising and echo cancellation aren't working, so if you need this feature don't use this build in production but just for testing the change.

[Nael-Sayegh]

Hello,
Very good idea for the change. We should also see if, when a new item appears in the list, whether the screen readers will stay on the selected item or move to the new item each time? In some cases, it could be an advantage, but it could also be annoying.

[peter1384]

@valiant8086 don't worry, everything you said already implemented
@Nael-Sayegh yes, we don't have any focus problem and focus just stays at the current item you've selected yourself, and it won't jump around

[valiant8086]

Realizing that we're not totally committed to doing the list yet, and that it's still early for feedback about issues with it, I have time at the moment and the desire to experiment, so I'll just place everything I can find here, and this may or may not end up relevant or have an impact on the feasibility of this feature.

1. there are focus issues especially when shift+tabbing the list view usually isn't announced until you press an arrow key. When opening the context menu on an item nothing is spoken until you down arrow. This is with NVDA.
2. There's alt+c to copy message and alt+c to clear chat history, clear chat should be something else, alt+delete maybe. I see that it's actually ctrl+c to copy current message ctrl+a doesn't do anything and alt+a to copy all places an A in the input edit box. I tried alt+c and it closes the conversation, but doesn't clear it or copy anything. I imagine this is just because it's early still and the functionality hasn't had time to get flushed out.
3. I do see that copy all works if I just activate the context menu item for it, and I'm happy with the formatting.
4. Interesting, alt+c opens a menu when in the main tt window, not in a conversation
5. both the conversation list and the channel list don't read anything when just tabbing sometimes.
6. I figured the chat list would have columns, but so far I don't find any functionality as such. I tried to use NVDA's table navigation. I can go up and down with ctrl+alt+up or down, but left and right don't do anything. I kinda thought I might go left and hear the name of the sender, at least if it's an actual chat that has a sender name, and back right would have the message, and right again would have the timestamp, if enabled. It's something to think about doing if it's possible to do and if we stick with the list view.
7. pasting an e-book in the input edit crashes the client when press enter to send it, but it does so with the latest release as well. If crash can't be fixed, probably should put an arbitrary limit on character count allowed in input edit

[CoBC]

1: Can't reproduce with shift-tab on the list. Context menu announcement is a Qt issue present on all menu and already reported and hopefuly fix one day.
2: We'll implement shortcut to copy all more later is the feature is accepted. Noted for context menu accelerator conflicts
4: Alt-C open client menu, like in all previous releases
5: Qt issue already reported and hopefuly fix one day
6: History list don't have any column for now, we'll ahve to choose a format for this list is the feature is accepted
7: Strange, don't know why, maybe @bear101 will have an idea, but, in all case this bug is not related to history changes.

Note for focus issues, I'm currently trying to play with QAccessible to fix some Qt accessibility problems, and I'll open PR if I figure to implement something.

[valiant8086]

Created new issue #2323 discussing item 7, crash when sending very long text messages. Probably weird to mention it here, but I still had this convo loaded, and I figure this could potentially be a landing point when searching for the issue.

[va3ets200]

Speaking of context menu options, as it is right now, here on the Mac, with VoiceOver, which is what I'm using here, the context menus are something that we currently don't have access to at this point. This is one thing I'd definitely like to see fixed, . Currently, VoiceOVer users on the Mac are totally missing out on that, so if stuff related to chats, if a list view is implemented, is going to be put into context menus, access to them for VoiceOver users on the Mac is crucial. we should be able to hit VO-shift-M, and have context menus come up.

[lbk2907]

@CoBC
Where can I try this?
Anyway, I suggest so that this option/feature can be enable/disable.

[CoBC]

You can test the list by running this build:
https://github.com/BearWare/TeamTalk5/actions/runs/9230038697/artifacts/1536450018
Note, however the following: as this build was produced by GitHub CI, WebRTC is not included, so in this build denoising and echo cancellation aren't working, so if you need this feature don't use this build in production but just for testing the change.

[Muamalaljanahi]

hi @CoBC where do i find the build of this pr for MacOS, this link is for windows only

[lbk2907]

Thanks. I'll give it a try.

…

Message ID: <BearWare/TeamTalk5/repo-discussions/2313/comments/9613582@ github.com>

[lbk2907]

@@CoBC
Ok, I just test it out. Since some user like this feature and some of them don't like this feature, I stick with my oppinion.
Make this is an optional. If user want to use this feature, they can enable it and if user don't want to use this feature, they can turn it off.

A lot of apps use list instead of readonly edit field to display chat history now, so I thought it's time to do the same in TT.

From your above quote in #2310, maybe you can make this feature enable by default.

[CoBC]

Really not sure we can make it optional, because the widget class isn't the same, and code of class isn't the same also, so, to make it optional, we have: - To understand if it's possible to change a widget used in a .ui file following a setting key - Change the entire code of chattextedit class regarding state of the option It seams a bit complicate

[lbk2907]

Understood. So, you have any idea about this?

[lbk2907]

@CoBC
I think @valiant8086 mean about this is about QT5.15 since this test build is build using QT5.15 if I not mistaken.

There are focus issues especially when shift+tabbing the list view usually isn't announced until you press an arrow key. When opening the context menu on an item nothing is spoken until you down arrow. This is with NVDA.
Both the conversation list and the channel list don't read anything when just tabbing sometimes.

What you think?

[valiant8086]

For the record, I would prefer to go for the list view. If you can get it to work ok for the visual interaction, it should work a lot better for screen readers. The way it is now, it reads a lot of lines twice and it's just a mess. Qt really needs to work out how to fix that too though.

[lbk2907]

I also prefer the list view. Honestly, I like the interface. 😊

[valiant8086]

shameless bump. I'm feeling the desire to have this pull request accepted. I know there was resistance, but now that we have migrated fully to qt and dropped classic, the edit window is being a royal pain in the butt. When you receive a chat each message is repeated many times as you try to arrow through the chats. I'm hopeful we can get some traction on this. I think we should be able to find out if we can have solutions for any concerns the sighted user would have, and or some solution for this problem for the screen reader user. Having the chats in a list is super handy either way, so if you can figure this out I'd be very greatful.

[amirmahdifard]

very sad this is stil inactive. If this get to merge one day, finally we can take a good breth and get rid of the problems of reading chats with read only editbox