These are more common than we thought, good examples are pinned or
searched messages - which are not going to be in the room's history
unless you happen to have them loaded. But currently our message menu
infrastructure expects them to be, since its looked up by the room +
event ID.
To fix this is simple, we now move the job of finding the event to the
caller which may use a model instead. I didn't fix all existing
call-sites yet, mainly the message menu opening one since that was the
most obvious bug. But this opens up the door for other assumptions about
room history to be fixed too.
I had to do a bit of C++ re-jiggering in order to expose useful
functions to QML.
This is that bug that causes reply colors to be white, and this error to
print in the log:
qrc:/qt/qml/org/kde/neochat/messagecontent/ReplyComponent.qml:41: TypeError: Cannot read property 'color' of null
The reason why this happens is inside of EventMessageContentModel, it
needs to be able to find the relevant event in the room to fetch the
room member (and then their color.) Dependent on many variables to
align, this can happen easily if you are faster than your server giving
you said events.
But this is an easy fix, we obviously get the event afterwards and just
need to re-evaluate the the author property. I also made sure it falls
back to some color instead of white, which will also quiet the error.
You were previously relegated to looking at any avatars or a buggy
tooltip, but suffer no longer! If you tap on a message's read marker, a
dialog will pop up listing the users who have read it.
Uou can also view their profiles from here, etc.
`decryptMessage` returns null if it fails to decode the passed message. This value
then got fed into `EventHandler::richBody` which logged a warning and cleared `m_pinnedMessage`.
If we instead retain the value as an `EncryptedEvent`, the UI will pin the encrypted event
placeholder instead of hiding the existence of pins.
`room()->decryptMessage()` returns null if the message fails to decode. Since elements of `m_pinnedEvents`
get directly dereferenced in getEventForIndex, storing null values leads to a segfault.
In this case we should retain the EncryptedEvent to let the UI report the error.
I added a separator, made it so the "Copy Room ID to clipboard" button
is always shown, and made it more obvious that "Upgrade Room" prompts
you first.
This is a common feature in other chat applications (like Discord) as a
way to keep track of important information. While there isn't a standard
API for this, we can use account data to store notes.
This can happen if the user doesn't have an avatar set, as there's an
assert check inside of makeMediaUrl. We can avoid this by checking if
the string is empty before calling that.
The favorites action doesn't really deserve space here IMO, and that's a
pretty list-specific action you're more likely to do elsewhere.
For the Pinned Messages action that can be opened at the top on desktop,
but we still need it on mobile. So now it's selectively hidden based on
that.
Changed a check to use isDirectChat (which is a clearer indication of
what we want.) I also made sure not to show the account name if you only
have one, since that's just useless noise.
Since Matrix allows users to have different profiles on a room and
"outside of room" level, it's nice to have the ability to switch between
them on-the-fly.
If a setCurrentRoom call changed the active space at the end of its execution, the new room's ID ended up still being written to the old space's lastRoomConfig.
By extracting this space selection logic into a helper function, we can now calculate this value earlier and use it as the space id when writing lastRoomConfig.
- Open the menu right beneath the button
- Use pressed state for the button while the menu is open
- Close the menu when clicking the button again
- Hide the tooltip while the menu is open
Our previous iteration is hitting some limitations as the power of
profiles on Matrix grows. For example, where do we put common rooms or
extra profile fields?
I re-arranged everything to group similar actions together - instead of
throwing it all into one big list. We basically trade vertical for
horizontal space, and gives us more headroom for extra fields when we
want to add more.
In my opinion, the significance of these options was still not super
clear. It wasn't obvious that the setting under Appearance will disable
them globally, and that the per-room option was discoverable.
Another change was using the term "Link preview" instead of "URL
preview", which is more common verbiage in chat applications other than
Element.
We use the "ignore" terminology elsewhere, so saying "block" here is
kinda weird. I also made it clearer that this also rejects the invite,
in case that wasn't obvious.
I recieved a few invites from unknown users, and I had no idea who they
were/came from. I could check their profile to see if we had any rooms
in common, but there was no way to actually check their profile!
This makes it possible to open their profile by clicking their avatar
(like elsewhere) but also adds a button to make it even more obvious.
Direct chats by their very nature is between two users, and you usually
can keep track of who said what. There's no point in including the
sender's name here, and most other chat applications exclude it for this
reason (including Element X.)
The key can be in the unstable features list, but it can be false. This
stops some features showing up and hitting API that isn't actually
implemented.
The QML code of the various QML modules is compiled to C++ by
qmlcachegen and then compiled into the final binary. Unfortunately, in
the current setup, the plugin for the org.kde.neochat QML module is not
linked into the app because qmlimportscanner can't find usages of it. No
generated C++ code for that module is then run and the QML is
interpreted from its bytecode instead.
This is likely due to the project not following recommended QML
structure and because it is not using qt_* variants of certain cmake
commands. It should not be necessary to link against the plugins
manually.
As a quick fix, link against the plugin explicitly and use qt_*
variants of cmake commands to help qmlimportscanner and to pick up the
existing C++ code.
I wondered for a while (and could tell) when people were using NeoChat
because they would react with cold, monochrome hearts. Let's add more
color to our world!
I noticed a bit of an annoying behavior with the quick format bar. Whenever I make a typo when writing a message I usually go back with a ctrl+shift+arrow selection to correct it, and that of course triggers the bar, but then there wasn't any obvious way to make it go away (other than pressing backspace or delete, [ChatBar.qml#L339](https://invent.kde.org/network/neochat/-/blob/master/src/chatbar/ChatBar.qml?ref_type=heads#L339)), so it'd always be stuck visible until I clicked somewhere with my mouse, which I found somewhat annoying.
This intends to fix that, by hiding it whenever the selection is cleared, which seems like a reasonable and expected behavior to me. I would also be okay with making it dismissable with escape, if this current suggestion has some unintended side-effect that I've missed.
I also think that this should in practice "solve" this bug https://bugs.kde.org/show_bug.cgi?id=511590 but I didn't link it directly as their suggested solution is smarter placement of the bar.
"X has put Y out of the room" is a British English style sentence. Which
is fine, but I'm using en_US, not en_UK.
Re-phrase this to sound a bit more American (which is the linguistic
style we use for the base strings), and then count on the en_UK
translators bringing back the old phrasing for en_UK.
