UnigramDev/Unigram/develop • 206109c • 3 files, +6/-2 Update libvlc build script UnigramDev/Unigram/

UnigramDev/Unigram/develop • 206109c • 3 files, +6/-2
Update libvlc build script

UnigramDev/Unigram/develop • 45d151b • 2 files, +32/-13
Probe a batch of files concurrently

The batch CreateAsync overload was still the serial loop the popup stopped
using, and the share target had become its only remaining caller, so sharing
thirty photos typed them one at a time before anything was sent.

It is now an ordered wrapper over ProbeAsync: concurrent, with results written
into a positional array so the order the caller gave survives, and failures
dropped at the end. Same contract, so no call site changes.

Order matters to the one caller: SendMessagesView attaches the caption to the
last item of the grouping, and GetItemsView needs the whole set before it can
group at all.

Streaming does not apply there and is not attempted. That view is an animation
and a progress bar, swapped in after the chats have been picked, so there is no
list to append into as items land -- only the pipelining was missing.

Its second stage is left alone: each InputMessageContent is still built
serially through MessageFactory, which for a large share is plausibly the
bigger delay, but parallelising it touches TDLib generation, ordering and
resource pressure at once and wants to be its own change.

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

UnigramDev/Unigram/develop • 4230adc • 3 files, +67/-36
Clear the dead branches out of SendFilesPopup, and log what it swallowed

FileItem_PointerEntered read an item it never used, through
ItemFromContainer on the template root rather than the container, so it was
always null anyway. Its glyph assignment was also unguarded where the matching
PointerExited uses ?.; both do now.

OnContainerContentChanging had a branch setting AspectView.Constraint that
cannot run. The template selector only ever returns FileItemTemplate or
AlbumTemplate, both rooted on a plain Grid; MediaItemTemplate, the one rooted
on an AspectView, is only used as a Button.ContentTemplate inside
StorageAlbumPanel and so is never a container's ContentTemplateRoot.

The popup's two catch { } now record what they caught. Reading a data package
is someone else's data over remote calls, so they have to keep swallowing, but
silently meant a paste that did nothing left nothing to look at. The per-file
catch in ProbeAsync logs too: the per-type factories already return null for
the expected "this is not a photo" case, so reaching that handler is a
surprise. Their own catch { return null; } is left alone, being both the
documented contract and, at one entry per unsupported file, a good way to flood
a 200 entry ring buffer that ships with crash reports.

Also folds the glyph expression, which appeared three times, into GlyphFor.

Three findings from the review doc do not survive a second look and are
corrected there rather than acted on. FindName on a template root is a
namescope table lookup rather than a tree walk, and the filename substrings run
once per row realization. Extensions.Prepend is misnamed and appends, so the
log line is linear and in natural order, not quadratic and reversed. And the
LINQ passes in IsMediaAllowed and TitleText use static lambdas the compiler
caches, on a path that runs about ten times per popup. Churning code for a cost
that is not there is how a file gets worse.

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

#unigram