Since #1834, images were not opened in the media preview again but
opened with an external app.
This was because since #1834, only slides that return true on
`hasImage()` are shown in the media preview, i.e. gifs, images and
videos.
Now, the problem was that images were shown as DocumentSlides under
some circumstances, which return `false` for `hasImage()` (naturally).
fix#1836
AvatarSelector is mostly copied from AttachmentTypeSelector. I first started to make it a subclass, but there were so many functions that had to be changed that I decided against it (esp. also the constructor, so I would have had to create another constructor to allow AvatarSelector to bypass the "normal" constructor). Could still be done though, of course.
I think (hope joy) that the commits are clear enough that this can be reviewed commit-by-commit. In the first commit, commenting out code means "Moved somewhere else"
I found it easier to look at the first commit using gitk than GitHub as GitHub doesn't show it as copied from AttachmentTypeSelector but as a new file. (of course you can also just review normally, going throug it file-by-file :)
* Don't show remove button if there is no image yet
* Remove unnecessary animation that just made things look worse
* Delete now-unused ClearProfileAvatarActivity
* For groups, also use the attachment-chooser-dialog
* Remove confirmation dialog for removing avatar (The user has to confirm anyway, and this was not correctly translated)
fix#1816
The problem was:
- as @link2xt already wrote, the onclick listener only checks if the mime type is `image/` or `video/`.
- then `PagingMediaLoader` loads all images and videos of the current chat with `context.getChatMedia(msg.getChatId(), DcMsg.DC_MSG_IMAGE, DcMsg.DC_MSG_GIF, DcMsg.DC_MSG_VIDEO)`. We need _all_ images so that the user can swipe back and forth.
- The correct image to be shown can't be found, the MediaPreview is opened anyway. As the correct image can't be shown, the first image in the chat is shown.
For long subject it's ellipsized (`…`) now, but I think that there is no need to show the full subject somewhere, it usually doesn't contain _that_ important information and can be seen in full in the normal chat view
if the original author of a quote is shown
and known to be overridden,
that should be marked with the character '~'
as for the normal names,
esp. as they are look very similar otherwise,
eg. also bold, also colored.
the missing '~' looks like a bug here.
successor of #1808
this is just a very simple approach to move forward.
to mark overridden names, a "~" is prefixed.
the idea with using a dedicated color for these names:
as we do not really know
if the address is a generic sender address or belongs to the user,
it makes sense to keep the color used for the name and do not use a
dedicated grey or so.
i think, it is not even worth to detect that better:
it is pretty nice to have senders in mailinglist marked nicely,
all the time.
currently, the "~" is only added to the bubbles - it is not there
in the chatlist-summary (that would needed to be done in core)
and also not in forwarded by, notifications, clipboard etc. i'd say currently,
this is not needed, however, with the current approach it would be doable
(if we mark possible impersonation by colors or icons that may be
much more complicated)
adaption on other uis would also be pretty simple with this approach,
and imho, this `~Max Mustermann` looks pretty nicely
and even intuitive in a way.
drawback of the approach is that user may user `~`
as the first character of their names, we could target that by
adapting dc_msg_get_displayname() in the core, if we want to keep this approach,
however, maybe it is also not worth, the "~" is more a flaw than a feature,
also that would result to "~~Name" in the bubbles.
i do not see how that can be used to trick users when beeing added.
names as "foo 🔒" might be more dangerous here, when it comes to trick users.
adbenitez