UnigramDev/Unigram/develop • dbdb4b7 • 6 files, +271/-230
Give SendFilesPopup rows of its own

StorageAlbum was answering two questions at once. It means one outgoing
message, which is what GetItemsView produces, but the template selector read it
as "a row that draws a mosaic" -- and those disagree in both directions, so
UpdateCollection had to lie three times to bridge them.

A standalone muted video was wrapped in a one-item album with a negative
ordinal, to keep a thumbnail it would otherwise lose. A documents album was
expanded and its grouping thrown away. And a files-mode row had its item
wrapped in a StorageDocument purely to carry the glyph, which
ItemsView_CollectionChanged then unwrapped again to get back to the item the
popup actually holds.

The list now holds a StorageRow: a MosaicRow of media to draw as a mosaic, or a
FileRow of one item with the flag that used to be a wrapper object. The
selector asks the question it means. StorageAlbum goes back to being purely a
send grouping -- Ordinal, Update, the mosaic layout and the display constants
all moved to MosaicRow, and StorageAlbumPanel became MosaicPanel so the naming
stops contradicting itself.

That removes a bug rather than only tidying. OnContainerContentChanging set the
delete button's Tag to the displayed item and Remove_Click looks that up in
Items, but in files mode the displayed item was a wrapper that was never in
Items, so the removal found nothing: deleting a photo or video row while
sending as files did nothing at all. FileRow.Media is the item itself.

Two things kept as they were. Files mode still names the file rather than the
track, which needed an explicit guard once the wrapper stopped hiding the audio
type. And mosaic identity counts mosaic rows rather than list positions, so a
file row appearing between two of them does not renumber everything after it.

StorageDocument's wrapping constructor and its Original property go too, the
popup having been their only consumer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • eb349af • 7 files, +1556/-22
Paste rich HTML into the chat field as blocks

Pasting into the chat field took plain text and nothing else, so copying out of
the rich editor lost every quote, list and table on the way back in.

Adds RichHtml.Parse: the clipboard HTML the editor writes — and the dialect
Telegram Android writes — read back into page blocks. Unlike Android, whose
editor holds a flat list of rows, this builds the nested pageBlock* tree TDLib
expects, and closes the tags HTML closes for you (an unclosed <p> otherwise
swallows the rest as one paragraph, and real clipboard HTML is full of them).

A paste becomes message text whenever TryGetFormattedText can say the whole
thing with entities. When it can't, only the app's own content — stamped with
data-telegram-rich on copy — reopens the rich editor, on the field's text split
around the pasted blocks: it's a separate window and a paid feature, so a
heading copied from a web page falls back to a plain paste instead.

Media is dropped. The HTML carries only a file id, which means nothing outside
the process that copied it, so a photo can't be rebuilt here — Android does the
same with an id it can't resolve, and an orphaned caption stays as a paragraph.
What markup can't express — a button's style and type — travels as the TDLib
JSON ClientJson reads back.

SendRichMessage now opens the editor on an existing rich draft rather than on
the text field, and PasteRichMessage splices into the same source of truth.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram