На мой взгляд, необходимость иметь контент, который можно прокручивать, и контент, который можно масштабировать, очень разные. Я понимаю, что при масштабировании контента его часто также необходимо прокручивать, но мне любопытно, было ли какое-либо соображение относительно создания этих отдельных элементов управления? Возможно, с помощью масштабируемого элемента управления, выходящего из элемента прокрутки.
Меня беспокоит следующее: 1) ScrollViewer делается чрезмерно сложным путем добавления функций, связанных с масштабированием, которые большинству не понадобятся; 2) для тех, кто ищет элемент управления для увеличения содержимого, не очевидно, что ScrollViewer поддерживает это.

Кроме того, в рамках предложения я хотел бы увидеть возможность прокрутки к определенному элементу в средстве просмотра прокрутки. Теоретически это может сделать разработчик, измерив все элементы перед ним и затем прокрутив его до соответствующего смещения, но это может быть сложно сделать с виртуализированными списками, и (на мой взгляд) это достаточно распространенный сценарий, когда многие приложения ( и разработчики) выиграют от того, что это будет встроено.
Подумайте, где элемент добавлен в «список», и разработчик хочет, чтобы этот элемент был видимым. Или рассмотрите страницу с основным / подробным представлением, где страница открывается в подробном элементе ниже по списку, но разработчик хочет убедиться, что выбранный элемент в главном списке отображается, поэтому он обеспечивает контекст для того, что показано в подробный вид.

Точно так же было бы полезно иметь возможность гарантировать, что элемент остается в видимой области, в то время как другие элементы в прокручиваемых областях удаляются из визуального дерева (или добавляются в него). Я не уверен, как лучше всего это сделать, но очень плохо, когда выбранный элемент в прокручиваемой области перемещается из-за того, что фоновое действие (или поток вне пользовательского интерфейса) удаляет или добавляет другие элементы в прокручиваемую область.
Если элемент перемещается по мере того, как вы нажимаете / нажимаете на него, это приводит к ужасному удобству использования. Перемещение выбранных / выбранных элементов за пределы видимой области также может вызвать проблемы с инструментами специальных возможностей и программами чтения с экрана.
Я знаю, что есть потенциальные проблемы с попыткой сохранить элемент в том же положении, пока все вокруг него перемещаются (особенно, если этот элемент удален из другого места), но ничего не делать не кажется достаточно хорошим.

Спасибо @mrlacey. Я вижу, что функция масштабирования будет менее заметна в существующем ScrollViewer, а также в этом предложении. Я добавил это как открытый вопрос для обсуждения, поскольку это будет еще одна отправная точка от существующего UWP ScrollViewer (возможно, к лучшему?).

Виртуализация усложняет задачу, поскольку сначала может потребоваться создать конкретный элемент и прогнать его через систему макета, чтобы получить позицию, к которой вы затем можете прокручивать. Вот почему в прошлом у некоторых элементов управления (например, ListView) был свой собственный метод ScrollIntoView, который обрабатывает вышеуказанное, чтобы упростить метод StartBringIntoView, который можно использовать для очень простой прокрутки к элементу, и имеет ряд параметров, обеспечивающих детальный контроль над тем, в каком месте окна просмотра он попадает, когда он появляется в поле зрения. Подход StartBringIntoView работает даже в сценариях с вложенными поверхностями прокрутки, поскольку он генерирует запрос, который всплывает для каждого элемента управления прокруткой, чтобы ответить. По сути, это то, что происходит, когда элемент получает фокус клавиатуры / GamePad / экранного диктора. Конечно, для этого требуется, чтобы у вас сначала был UIElement, который вы не можете использовать в сценарии виртуализации без возможности явного запуска элемента, который должен быть реализован. Было бы полезно иметь способ явно запускать реализацию элемента? Помимо прочего, вы можете затем использовать его для запуска StartBringIntoView.

Re: сохранение позиции элемента при добавлении / удалении другого содержимого или изменении размера ... Полностью согласен, что ничего не делать недостаточно. Именно поэтому существует функция привязки прокрутки . :) Это малоизвестная возможность, которая в прошлом была встроена в панели виртуализации для ListView / GridView. В последних выпусках мы прилагали явные усилия, чтобы отделить такие вещи от того, что они доступны только в ListView.

Если нужно изучить идею расширенного ScrollViewer, возможно, команды Fluent Design посоветуют вам, как обрабатывать параллакс и элементы со значениями глубины z, установленными по умолчанию.

По мере того, как XAML переходит в 3D-представления для MR-приложений, а глубина и тени переходят в 2D XAML - как прокрутка будет перемещать элементы с разными значениями глубины, как тени могут отображаться над или позади индикаторов прокрутки и другие проблемы, которые могут возникнуть в 3D-экспериментах команды XAML - может быть встроена в то, что может стать новым значением по умолчанию, поскольку библиотека пользовательского интерфейса Windows постепенно становится новым значением по умолчанию.

На мой взгляд, необходимость иметь контент, который можно прокручивать, и контент, который можно масштабировать, очень разные.

За исключением веб-браузеров, приложений для графического дизайна, офисных приложений, средств просмотра PDF ... всего, что показывает документ с содержимым.

Согласитесь с @mrlacey, что

Спасибо всем! Мы собрали некоторую телеметрию относительно того, какие свойства приложения обычно устанавливают в своей разметке, и ZoomMode отображается сразу после * ScrollMode и * ScrollBarVisibility. В большинстве случаев приложения не меняют никаких свойств. Что я заметил, когда устанавливаются свойства ScrollMode и ScrollBarVisibility, так это то, что часто требуется включить горизонтальную прокрутку содержимого. Введение свойства ContentOrientation призвано упростить это. После горизонтальной прокрутки следующим наиболее распространенным сценарием является масштабирование.

Вместо того, чтобы вводить отдельный (производный) элемент управления для решения проблемы обнаружения масштабирования, я считаю, что правильная документация / образцы могут быть более эффективными.

А как насчет добавления Behavior или Context Enum?

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.Scroll;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.ParallaxScroll;

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; очень сбивает с толку. Я думаю, что ZoomMode следует оставить как есть.

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; очень сбивает с толку. Я думаю, что ZoomMode следует оставить как есть.

Я, вероятно, должен был предварять это предложение как обращение к комментариям, которые думают, что должен быть производный элемент управления для масштабирования содержимого, а не для прокрутки.

Для меня действительно имеет смысл встроить функцию масштабирования с помощью ScrollViewer , особенно на сенсорных устройствах. В настоящее время нет простого способа выполнить произвольное панорамирование / масштабирование / поворот изображения / элемента управления в UWP, и многие связанные вопросы были заданы в StackOverflow и GitHub (например, Добавить элемент управления перетаскиваемым содержимым ).

@micahl , я предполагаю с масштабированием и

Поддержка жестов вращения

этот сценарий будет поддерживаться изначально в будущем?

Для меня действительно имеет смысл встроить функцию масштабирования с помощью ScrollViewer , особенно на сенсорных устройствах. В настоящее время нет простого способа выполнить произвольное панорамирование / масштабирование / поворот изображения / элемента управления в UWP, и многие связанные вопросы были заданы в StackOverflow и GitHub (например, Добавить элемент управления перетаскиваемым содержимым ).

Если есть необходимость в большем управлении масштабированием и прокруткой ...

ScrollViewer.ScrollBehaviour = ScrollBehaviour.ZoomAndScroll;

Но на сенсорных устройствах это кажется естественным, когда пальцы могут щипать и скользить. Однако для масштабирования без касания должны появиться кнопки [+] и [-]. Или, возможно, если бы это было только масштабирование, тогда перетаскивание ползунка полосы прокрутки увеличивало и уменьшало масштаб.

Если вы посмотрите на пользовательский интерфейс Microsoft Word, в строке состояния есть элемент управления масштабированием. И полосы прокрутки для области документа.

Поддерживает ли масштабирование мыши то, что должно быть встроено в новый элемент управления ScrollViewer? Итак, когда включен ZoomMode или свойство Behavior позволяет масштабировать - тогда появляются кнопки «Плюс» и «Минус»?

@JustinXinLiu Для поддержки жестов поворота, вероятно, потребуется поддержка InteractionTracker (@likuba).

@mdtauk Новый ScrollViewer будет поддерживать масштабирование колесика мыши с помощью Ctrl + колесико мыши, аналогично существующему ScrollViewer. Мне неясно, должен ли элемент управления иметь кнопку плюс / минус по умолчанию при включенном масштабировании. Мое текущее впечатление таково, что виды приложений, которые обычно позволяют масштабировать (например, приложение документа содержимого), по-разному включают эти кнопки в свои приложения. Например, - / + в строке состояния, отделенной ползунком (например, Office), или просто - / +, который отображается вертикально под другими командами (например, Maps).

@micahl Я не понимаю, почему ScrollFrom называется именно так. Разве это не похоже на ScrollBy, но с параметром скорости?

@adrientetar , вы спрашиваете, почему бы не использовать еще одну перегрузку ScrollBy с другим набором параметров вместо того, чтобы называть ее ScrollFrom?

Да, я полагаю, но я полагаю, что концепция ScrollFrom состоит в том, чтобы двигаться в направлении с заданной скоростью? в отличие от ScrollBy, который просто перемещается в заданную точку.

Верно. Мы имели в виду 3 ситуации:

1. Меня не волнует мое нынешнее положение. Я хочу выполнить прокрутку / масштабирование ДО определенного пункта назначения.
2. Меня волнует моя текущая позиция, и я хочу прокрутить / увеличить на определенную величину относительно этой позиции.
3. Меня не волнует конечный пункт назначения. Я просто хочу прокрутить / увеличить ОТ моего текущего положения.

Сценарий для последнего может быть чем-то вроде щелчка колесика мыши для панорамирования. В зависимости от положения курсора относительно того, когда он был нажат, вставляется некоторая инерция прокрутки от текущей позиции (какой бы она ни была).

Спасибо, это проясняет ситуацию. Я думаю, что больше хочу использовать ScrollBy для моего собственного опыта с колесиком мыши, но я вижу, что ScrollFrom полезен в определенных случаях.

В текущем элементе управления ScrollViewer можно выполнить привязку к свойствам ViewportWidth и ViewportHeight, но в настоящее время это не представляется возможным в новом элементе управления ScrollViewer. Это будет добавлено?

@lhak , с чем бы вы

@micahl Я почти уверен, что использовал эти значения в прошлом для некоторых расчетов. Не уверен, что привязался к ним.

@ michael-hawker, чтобы было понятно, свойства будут доступны в ScrollViewer. Однако в предлагаемом API они представлены как обычные свойства, а не как DependencyProperties. Эти же значения будут доступны как часть свойства ExpressionAnimationSources для ситуаций, когда кто-то создает управляемые вводом анимации на основе композиции.

В настоящее время я использую в своем приложении код, похожий на следующий:

<ScrollViewer x:Name="outputScrollViewer">
  <Viewbox MaxWidth="{x:Bind outputScrollViewer.ViewportWidth, Mode=OneWay}" MaxHeight="{x:Bind outputScrollViewer.ViewportHeight, Mode=OneWay}">
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

Это позволяет прокручивать / масштабировать внутренний элемент xaml (который имеет фиксированный размер), сохраняя при этом его соотношение сторон. Поведение аналогично приложению фотографий, отображающему изображение, за исключением того, что элемент xaml никогда не меньше области просмотра средства просмотра прокрутки.

@lhak , хороший сценарий! Обдумывая вслух, как этот сценарий может быть включен в текущее предложение ... Я думаю, мы могли бы добавить еще один вариант для свойства ContentOrientation. Текущие варианты в предложении:

• Нет = Нет предпочтительной ориентации. Дайте контенту неограниченный доступный размер в обоих направлениях.
• По горизонтали = предоставьте содержимому неограниченный доступный размер только по горизонтали и ограничьте высоту области просмотра во время макета.
• Вертикальный = транспонирование по горизонтали

Четвертый вариант - ограничить высоту и ширину во время макета размером области просмотра. На данный момент я назову это ориентацией «Окно просмотра», хотя у меня неоднозначная реакция на его название.
По крайней мере, в (более распространенном?) Случае с изображением, я считаю, что это сделало бы окно просмотра и привязки ненужными, поскольку «правильная вещь» должна происходить просто как часть процесса макета.

<ScrollViewer ContentOrientation="Viewport">
  <Image Stretch="Uniform" .../>
</ScrollViewer>

Для более сложного контента вы можете обернуть его в окно просмотра и по-прежнему пропустить привязки.

<ScrollViewer ContentOrientation="Viewport">
  <Viewbox>
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

@micahl Есть еще один вопрос: я хотел бы изменить обработку колесика мыши в Scroller, чтобы сделать масштабирование быстрее (с большим шагом) и удалить анимацию сглаживания. Кажется, что нет API для настройки масштабирования колеса, нужно ли мне обрабатывать событие колеса мыши вручную?

Возможно, вам придется управлять колесом мыши вручную, но будет жаль, если окажется, что вам придется заново реализовать то, что делает элемент управления. Мы думаем, что есть способ добиться того, чего вы хотите. Суть его в том, чтобы установить для ZoomInertiaDecayRate некоторое значение, близкое к 1.0, а затем определить точку повторной привязки масштабирования. Это кое-что, что стоит попробовать после того, как мы добавили свойство ZoomInertiaDecayRate и исправили некоторые проблемы, связанные с обязательными точками привязки.

Если это не сработает, вы можете вернуться к попытке справиться с этим самостоятельно, установив IgnoredInputKind = "Mousewheel", а затем либо подклассифицировав Scroller, чтобы переопределить OnPointerWheelChanged, либо добавить обработчик событий для события PointerWheelChanged в Scroller.

@micahl Спасибо! Я не уверен, по какому сценарию вы откалибровали поведение колесика мыши, лично мне нравится, как оно есть, например, в Adobe XD: кажется, есть немного ускоряющейся анимации, но она быстрая и имеет достаточно большие приращения масштабирования. Анимация масштабирования с помощью колеса прокрутки мыши кажется немного вялой и имеет очень маленькие приращения масштабирования imo.

@adrientetar , хорошие отзывы. Мы можем исправить это.

Любые переменные, управляющие приращениями и значениями, могут быть преобразованы в переопределяемые свойства.

Верно. Одна из проблем для нас здесь заключается в том, что в Win10 версии 1809 и более поздних версиях элемент управления передает ввод колесика мыши в базовый InteractionTracker, чтобы он мог обрабатываться вне потока пользовательского интерфейса для более плавного движения. Эти переопределяемые свойства необходимо сначала предоставить на нижнем уровне. Для версий Win10 до 1809 года мы добавляем логику, чтобы колесо мыши управляло процессом ввода в поток пользовательского интерфейса.

Мы могли бы подумать о том, чтобы иметь какое-то поведение, при котором мы предоставляем некоторые переопределяемые свойства, и если они явно заданы, мы возвращаемся к тому, чтобы колесо мыши процесса управления находилось в потоке пользовательского интерфейса. Если / когда эти свойства существуют на более низком уровне, мы могли бы переключиться на их использование и вернуть их композитору. Прокрутка, вероятно, будет не такой плавной для колеса мыши. Может, здесь все в порядке?

Значит, текущее поведение масштабирования встроено в InteractionTracker без возможности его переопределения? И я думаю, теперь нет возможности изменить его, потому что это нарушит обратную совместимость 🤔 cc @likuba

Я думаю, что в InteractionTracker есть несколько вариантов, которые могут здесь помочь 😊. В частности, мы создали такие функции, как PointerWheelConfig и DeltaScaleModifier, чтобы включить эти типы настроек. Мы собираемся синхронизироваться и посмотреть, может ли их использование в элементе управления позволить чему-то здесь произойти без проблем / рисков, о которых вы упомянули выше.

@micahl У меня интересная ситуация с проектом, над которым я работаю, и мне пришлось написать свой собственный просмотрщик прокрутки для PoC, но я хотел бы знать, есть ли у вас какие-либо планы (или этот элемент управления уже поддерживает это) для следующий сценарий:
Скажем, у вас есть гигантский холст размером 10000x5000, поэтому, чтобы перемещаться по нему, вы инкапсулируете его в программе просмотра прокрутки.
Теперь на холсте у вас есть 2 InkCanvases (или больше), и вы хотите писать на обоих (или более), разными пальцами или одним пальцем и 1 указателем мыши. Как бы вы этого достигли (или это вообще возможно) с помощью этого контроля? :)
Я видел поведение по умолчанию: как только вы касаетесь чего-либо еще во время рисования на одном InkCanvas, этот конкретный InkCanvas запускает «PointerLost», и все - больше нечего делать.
Очевидно, что мой просмотрщик прокрутки далек от совершенства, поскольку я написал его сам - так что я хочу посмотреть, возможно ли это с этим элементом управления?

Спасибо большое!

Привет @stefangavrilasengage , интересный сценарий. :) Исходя из вашего PoC, каково ожидаемое поведение, когда палец опускается на InkCanvas, а затем начинает двигаться? Он рисует или панорамирует?

Привет, @micahl - спасибо за ответ! Полагаю, вы уже догадались, что это что-то вроде приложения для цифровой доски.
Теперь я представлю, что происходит сейчас:

• ScrollViewer (по умолчанию): достаточно рисования одним пальцем на InkCanvas. При 2-м пальце 1-й InkCanvas теряет ввод.
• ScrollViewerEx (настраиваемый элемент управления): используйте столько пальцев и столько InkCanvases для рисования, и это работает.

Это помогает? :)
Спасибо !

@stefangavrilasengage Я спрашивал, что устраняет неоднозначность между панорамированием одним касанием (поведение по умолчанию для ScrollViewer) или рисованием чернил. Здесь есть внутренний конфликт. Как решить эту проблему? Требуются два пальца для прокрутки, как на карте? Использовать кнопку редактирования для входа / выхода из режима редактирования? Так далее...

@micahl Мои извинения - забыл упомянуть, как я решил конфликт.
У объектов, которые у нас есть на холсте, есть свои чернила внутри контейнера Win2D. Только если вы войдете в режим редактирования для каждого объекта, InkCanvas будет представлен наверху для редактирования (с настраиваемой сушкой).
Поэтому в моей ситуации (не уверен, применимо ли это к кому-либо еще), если у вас есть активный «drawable» InkCanvas, тогда ничего не должно доходить до ScrollViewer.
Мне было бы любопытно узнать о случае использования, в котором, по вашему мнению, это не применимо, если таковые имеются?

Спасибо !

Трудно поверить, что это первый раз, когда мы с @micahl замешаны в проблеме с github!

Трудно поверить, что это первый раз, когда мы с @micahl замешаны в проблеме с github!

Прости за это ! Отредактировано!

@micahgodbolt, возможно, не последний. ;)
@stefangavrilasengage спасибо! Это отвечает на мой вопрос. Я заметил, что замена ScrollViewer чем-то еще, например Border, в качестве родительского элемента Canvas, содержащего несколько элементов управления InkCanvas, не вызывает такой же проблемы. Итак, я обратился к некоторым людям изнутри, чтобы понять, что может вызывать сбой функции multi-input / multi-InkCanvas, когда это происходит внутри ScrollViewer.

@stefangavrilasengage , чтобы выяснить, почему это не работает, потребуется время / расследование. Давайте проследим это отдельно от этого предложения. Вы откроете для этого вопрос?

@micahl У меня проблема с Scroller, когда прокрутка и масштабирование моего контента в OnControlLoaded ставит меня в неправильное положение. Если я прокручиваю только прокрутку, я оказываюсь в правильном положении, но если я увеличиваю масштаб сразу после прокрутки, я полностью отключен, хотя я указал centerPoint = null, поэтому по умолчанию используется центр области просмотра (при просмотре кода, потому что там документации пока нет). С этим кодом .

Спасибо, что попробовали, @adrientetar! Давайте продолжим эту ветку сосредоточить на предложении. Можете ли вы открыть отдельный выпуск для того, что вы видите? В зависимости от того, где мы находимся в этой дискуссии, мы, возможно, захотим вернуться к этой теме, чтобы обсудить, оправдывает ли она внесение изменений в предложение.

@micahl Почему события ExtentChanged / StateChanged / ViewChanged имеют объект в качестве аргумента, а не, например, StateChangedEventArgs с членом состояния? Учитывая, что InteractionTracker выполняется в другом потоке, разве шаблон передачи сообщений (событие с аргументом) не предпочтительнее запроса свойства элемента управления в обработчике событий?

https://github.com/XeorgeXeorge/Extended-Image-Viewer

Ничего особенного, но первая часть этого репо демонстрирует, как реализовать масштабирование, даже когда горизонтальные / вертикальные полосы прокрутки заблокированы (отключены),

Проще говоря:
Позволяет панорамировать увеличенный контент при принудительной подгонке к
эффективный вертикальный / горизонтальный видовой экран.

Во время публикации обязательно включить свойство HorizontalScrollbarVisibility в ScrollViewer, чтобы на самом деле получить функциональную операцию масштабирования, и хотя могут быть лучшие способы обойти это, я думаю, что решение с двойной прокруткой, которое я скинул вместе, может быть достаточным достаточно.

@micahl Я вижу, что Scroller не отправляет события StateChanged при выполнении неанимированного масштабирования, это намеренно?
Я устанавливаю масштабирование CanvasVirtualControl, когда Scroller становится неактивным, как вы предложили в https://github.com/microsoft/microsoft-ui-xaml/issues/541#issuecomment -488749469, так что элемент управления не будет растеризован слишком большим части холста относительно коэффициента масштабирования. Но с неанимированным масштабированием мне нужно сделать это в то время, когда я вызываю метод ZoomTo, даже если изменение масштабирования не было реализовано (afaict).

@adrientetar , есть некоторые накладные расходы на создание аргументов событий для передачи туда и обратно между фреймворком и приложением. Поскольку аргумент события будет предоставлять только копию свойств, предоставленных отправителем, в нашем текущем проекте не должно быть аргумента события.

Да, текущий дизайн таков, что при неанимированном масштабировании вы вызываете программно StateChanged. События ZoomCompleted и ScrollCompleted будут возникать в ответ на программные изменения. IIRC они не запускаются изменениями со стороны пользователя. Вы можете использовать один из них, возможно, в сочетании с StateChanged. Как и fyi, событие ViewChanged возникает каждый раз при изменении представления (пользовательского или программного), что делает его очень чувствительным к производительности путем кода и не является тем, что вы хотели бы использовать.

Мы все еще прислушиваемся к отзывам, поэтому, если что-то покажется тупым, дайте нам знать.

Да, текущий дизайн таков, что при неанимированном масштабировании вы вызываете программно StateChanged.

Хорошо, теперь я понимаю. Возможно, событие может запускаться всегда и содержать параметр происхождения, например SetFocus, но, возможно, для этого есть некоторые накладные расходы.

События ZoomCompleted и ScrollCompleted будут возникать в ответ на программные изменения. IIRC они не запускаются изменениями со стороны пользователя.

Хорошо, поэтому для моего варианта использования мне нужно обрабатывать ZoomCompleted и StateChanged iff State == Idle, в зависимости от того, является ли изменение программным или нет. Разве это не странно? Я имею в виду, что разные события с разными названиями для одной и той же вещи только запускались по-разному 🤔

Мы с @RBrid коротко поговорили о введении нового состояния «Переход» и о некоторых незначительных переименованиях. Сообщите нам, будет ли это иметь больше смысла для вашего варианта использования.

Обсуждаемая идея заключалась в том, что когда изменение положения прокрутки / масштабирования будет обслуживаться (независимо от того, инициировано ли оно пользователем или программно), мы вызовем событие StateChanged и сообщим о текущем состоянии как о переходе. Вот как будет выглядеть последовательность программной прокрутки (анимированной, а не анимированной):

// программный запрос, анимированный
myScrollInfo = ScrollTo (100, animate = true);
// несколько тиков
StateChanged поднят (Scroller.State == Transitioning)
// несколько тиков
StateChanged поднят (Scroller.State == Animating)
// много тиков
StateChanged поднят (Scroller.State == Idling)

// программный запрос, без анимации
myScrollInfo = ScrollTo (100, анимация = false);
// несколько тиков
StateChanged поднят (Scroller.State == Transitioning)
// несколько тиков
StateChanged поднят (Scroller.State == Idling)

Мы, вероятно, захотим переименовать перечисление InteractionState во что-то вроде ScrollState, поскольку оно будет представлять больше, чем просто взаимодействия.

enum ScrollState
{
    Idling = 0,
    Transitioning = 1,
    Interacting = 2,
    Inertial = 3,
    Animating = 4,
};

@micahl Да, это очень похоже на то, что я ожидал! Тот, кто хочет обрабатывать только анимированные изменения, может перехватить состояние Animating. Что касается имен, я бы держал Idle not Idling («Scroller is idle» / «Scroller is animating»), Transitioning → Stirring? (Переход очень сбивает с толку, я бы предпочел, чтобы мы передали, что это в начале движения, так что перемешивание может работать лучше ), инерционный может быть дрейфующим 😛 но я думаю, что API Review также подойдет.

Перемешивание сначала заставило меня задуматься о смешивании. :) Обзор API захочет взвесить, когда мы доработаем имена и будем искать прецеденты. Всегда хорошо иметь несколько вариантов. Другими вариантами могут быть «Неизвестно» или «Ожидает рассмотрения». Существуют прецеденты в существующих API для обоих, а также для Idle, что означает, что мы, вероятно, не будем использовать Idling.

Классно классно. Ожидание sgtm, imo Unknown еще более сбивает с толку, чем переход.

@micahl - Функциональное требование номер 3 включает этот подпункт:

участвует в эффективных изменениях области просмотра (обязательно)

Этот подпункт относится к уже существовавшему событию FrameworkElement.EffectiveViewportChanged . Достаточно ли этого подпункта, чтобы сказать (косвенно), что асинхронная частичная загрузка контента по запросу также является требованием / приоритетом? Я имею в виду, например, эквивалент того, как работает ScrollViewer, когда MS Edge отображает увеличенную страницу документа PDF (или SVG, или другого сложного документа). Когда масштабирование составляет 900% (например), он не выполняет предварительную визуализацию всей страницы PDF с размером 900% по этим двум причинам:

• Эта задача рендеринга (с высоким процентом масштабирования) занимает примерно 3 ... 20 секунд, в зависимости от сложности документа (количества векторных элементов, эффектов и т. Д.), Размера документа и процента масштабирования. Эта задержка слишком велика для конечных пользователей.
• Визуализированное изображение (растровое изображение) всей страницы PDF может потреблять сотни мегабайт ОЗУ при высоком проценте масштабирования, поскольку это эквивалентно отрисовке с очень высоким разрешением DPI.

MS Edge визуализирует части увеличенной страницы PDF по запросу, то есть когда пользователь прокручивает эти части для просмотра. Этот метод позволяет избежать длительной задержки перед отображением страницы. Я предлагаю, чтобы функциональные требования явно упоминали этот сценарий, но также с косвенной поддержкой async Task . Когда неотрисованная (или не сразу доступная) часть прокручивается в представление, ScrollViewer может временно заполнить это пространство настраиваемым Brush а затем инициировать событие, а обработчик событий может запустить async Task для рендеринга (или иного извлечения / загрузки) детали. Позже, когда Task завершается, обработанная / полученная / загруженная часть отображается в ScrollViewer, закрывая пространство, которое было временно заполнено Brush .

Эта проблема касается не только дороговизны рендеринга при большом увеличении. Это также применимо к контенту, который извлекается по запросу. Например, представьте себе карту или спутниковое изображение, отображаемое в ScrollViewer. Части карты загружаются с сервера только тогда, когда пользователь прокручивает их для просмотра.

Следует ли разделить API, связанные с масштабированием, в производный элемент управления (например, ZoomViewer), чтобы ScrollViewer строго касался прокрутки?

Хотя мне очень понравилось добавление ScrollViewer.ZoomFactor , я был удивлен, увидев, что он был добавлен непосредственно в ScrollViewer. Я предположил, что было бы проще и надежнее поместить масштабирование в отдельный класс (не обязательно производный класс). Возможны как минимум 3 способа:

1. Класс с именем, возможно, ZoomViewer , который НЕ наследует ScrollViewer , но использует экземпляр ScrollViewer в качестве дочернего элемента (в своем ControlTemplate ).
2. Класс с именем, возможно, ZoomableScrollViewer , который наследует ScrollViewer .
3. Прямая поддержка масштабирования в пределах ScrollViewer , если это не слишком сложно или беспорядочно.

17 Предоставьте UX по умолчанию для поддержки щелчка средней кнопкой мыши и прокрутки. (Должен)
18 Поддержка режима щелчка и панорамирования с помощью мыши (например, перемещение содержимого в программе просмотра PDF). (Должен)

Я предлагаю подумать, следует ли убрать поддержку 17, потому что 18 работает намного лучше, чем 17, и почти никто не использует 17 на практике. По общему признанию, я мог бы подумать, что 17 означает нечто иное, чем предполагаемое вами значение (описание 17 - это всего лишь одно предложение, и я не на 100% уверен, что оно означает то, что я думаю). Разве не правильно сказать, что 18 очень удобен и прост в использовании, тогда как 17 - неудобная вещь, которую все пытаются использовать и избегают использования?
(Эта проблема меняется, если 17 необходимо по причинам доступности, но до сих пор я никогда не слышал, чтобы кто-нибудь говорил, что 17 является проблемой доступности.)

4 Возможность выполнять анимацию, управляемую вводом

Номер 4 - это проблема, связанная с доступностью. Я хотел бы попросить ScrollViewer (и все другие элементы управления в WinUI) соблюдать настройки доступности:

Windows 10 -> Пуск -> Настройки -> Легкость доступа -> Дисплей -> Показывать анимацию в Windows (Вкл. Или Выкл.).

К сожалению, за прошедшие годы я заметил много примеров, когда приложения Microsoft игнорируют настройки специальных возможностей Windows. Анимация отключена, но приложения Microsoft все равно отображают анимацию. Это вызывает реальные трудности у пользователей, которые полагаются на эти настройки специальных возможностей. Не у всех есть возможность наслаждаться анимацией без негативных побочных эффектов. Пользователи, которые не испытывают затруднений при просмотре анимации и т. Д., Могут столкнуться с трудностями в понимании значения настроек специальных возможностей в Windows.

Привет, @verelpode! @Predavid будет вести работу над новым ScrollViewer, поэтому я возложу на нее задачу.

17 Предоставьте UX по умолчанию для поддержки щелчка средней кнопкой мыши и прокрутки. (Должен)
18 Поддержка режима щелчка и панорамирования с помощью мыши (например, перемещение содержимого в программе просмотра PDF). (Должен)

Я предлагаю подумать, следует ли убрать поддержку 17, потому что 18 работает намного лучше, чем 17, и почти никто не использует 17 на практике. По общему признанию, я мог бы подумать, что 17 означает нечто иное, чем предполагаемое вами значение (описание 17 - это всего лишь одно предложение, и я не на 100% уверен, что оно означает то, что я думаю). Разве не правильно сказать, что 18 очень удобен и прост в использовании, тогда как 17 - неудобная вещь, которую все пытаются использовать и избегают использования?
(Эта проблема меняется, если 17 необходимо по причинам доступности, но до сих пор я никогда не слышал, чтобы кто-нибудь говорил, что 17 является проблемой доступности.)

@verelpode Я думаю, вы правильно поняли 17, и я согласен с тем, что 18 важнее и обычно более интуитивно понятны, чем 17. Но могут быть сценарии, в которых «щелчок левой кнопкой мыши и перетаскивание» уже используется для других целей, таких как выделение или перетаскивание + падение . Для таких сценариев было бы хорошо, если бы приложение могло разрешить прокрутку с помощью среднего щелчка (17).

Лично я время от времени использую в браузерах прокрутку со средним щелчком, где левый щелчок + перетаскивание вызывает либо выделение текста, либо перетаскивание + падение изображений. Браузер UWP будет иметь 18 отключенных и 17 включенных. Оба должны быть включены через отдельные свойства.

@lukasf

Лично я время от времени использую в браузерах прокрутку со средним щелчком, где левый щелчок + перетаскивание вызывает либо выделение текста, либо перетаскивание + падение изображений.

Хороший момент, когда нужно избегать остановки выделения текста и т. Д. Что вы думаете об этом возможном решении: сделайте щелчок средней кнопкой мыши для запуска режима панорамирования на основе мыши (18) вместо запуска неудобного режима 17.

Когда я смотрю на то, что делают другие приложения, некоторые приложения позволяют запускать панорамирование с помощью мыши, удерживая клавишу пробела при одновременном щелчке левой кнопкой мыши в области прокручиваемого содержимого. Это решение позволяет щелчку левой кнопкой мыши нормально работать в прокручиваемой области содержимого, поскольку режим панорамирования запускается только при нажатии клавиши пробела и щелчка. Я считаю, что панорамирование с помощью пробела + щелчок очень удобно, удобно и быстро.

Однако это решение «пробел + щелчок» проще реализовать в приложениях, которым не нужно отображать какие-либо редактируемые текстовые поля в области прокручиваемого содержимого. Если редактируемые текстовые поля действительно существуют в области прокручиваемого содержимого, то это будет проблемой, поскольку функция панорамирования не позволяет пользователям вводить пробелы в текстовых полях. Поэтому, как вы сказали, эта функция должна быть включена через свойство. В качестве альтернативы не используйте пробел, а вместо этого сделайте средним щелчком запуск режима панорамирования на основе мыши (18), и это устранит проблему, связанную с тем, что пользователи не могут вводить пробелы в текстовые поля.

@verelpode
Со всеми браузерами, а также множеством других приложений (Word, Adobe Reader, Outlook, ...), поддерживающих режим 17, я все еще думаю, что это должно быть реализовано. То, что вам лично это неудобно, не означает, что это бесполезно для других. Разумеется, оба режима должны быть включены, тогда разработчики могут решить, что использовать в их приложении. Это также позволит использовать пробел + щелчок, если это имеет смысл для приложения: включить режим 18 при нажатии пробела вниз, снова отключить его при нажатии пробела вверх.

@lukasf - Хорошо, звучит хорошо. Я думал, вы имели в виду, что если режим панорамирования (18) не предотвратит выделение текста или перетаскивание + падение изображений и т. Д., Тогда вы перестанете использовать режим 17 и переключитесь на 18, но теперь я вижу, что вы предпочитаете, чтобы оба режима были поддерживаться.

Спасибо за отзывы @verelpode и @lukasf , я согласен с вами, что в конечном итоге мы захотим, чтобы общедоступные регуляторы на элементе управления Scroller включали / выключали номера 17 и 18. Назовем их 17 = панорамирование с постоянной скоростью на основе мыши и 18 = панорамирование с помощью мыши.

Я только что разослал PR https://github.com/microsoft/microsoft-ui-xaml/pull/1472, чтобы добавить кое-какую исследовательскую работу, которую я проделал. Я хотел увидеть, насколько близко я смогу подойти к поддержке и 17, и 18 с помощью сегодняшнего Scroller.

Для 18 = панорамирование на основе мыши все прошло довольно хорошо, хотя решение на 100% привязано к потоку пользовательского интерфейса, в отличие от сенсорного управления или колесика мыши. Я использовал метод ScrollTo при прослушивании события PointerMoved мыши. В конечном итоге мы бы хотели, чтобы базовый компонент InteractionTracker обрабатывал движения мыши, как это происходит с движениями пальцев.

С 17 = панорамированием с постоянной скоростью на основе мыши все намного сложнее (опыт, который мне лично не нравится). Прототип далек от идеала, и я не пытался решить все проблемы, но две, в частности, касаются:

• во время панорамирования с постоянной скоростью (то есть панорамирования с нулевой скоростью) я не думаю, что есть способ с текущим Scroller, чтобы остановить движение, не возвращаясь в более старую позицию (с ScrollBy (0, 0)) . Просто невозможно достоверно узнать, насколько поток композиции ушел вперед над потоком пользовательского интерфейса. Таким образом, потребуется какой-то новый общедоступный API-интерфейс Scroller, чтобы остановить скорость без сбоев.
• Мне не удалось сохранить захват мыши после события PointerReleased мыши. Похоже, для этого потребуется новая функция фреймворка Xaml.
  В любом случае, это может быть еще один случай, когда мы хотим, чтобы лежащий в основе InteractionTracker обрабатывал часть опыта напрямую.
  Я обязательно учту это при обсуждении будущих функций Scroller / InteractionTracker.

@RBrid

Для 18 = панорамирование с помощью мыши, ... ...
С 17 = панорамированием с постоянной скоростью на основе мыши все намного сложнее (опыт, который мне лично не нравится).

Интересные результаты! В этом случае, учитывая трудности с 17 = постоянная скорость и учитывая, что 18 может быть реализовано таким образом, чтобы не препятствовать нормальному использованию левой кнопки мыши, то, по моему личному мнению, я думаю, что предложение, вероятно, следует обновить до откажитесь от 17 и поддержите 18, но, по общему признанию, я не знаю, сколько пользователей будут жаловаться, если 17 = постоянная скорость будет оставлена.

Спасибо @RBrid за эти исследования. Приятно слышать, что режим 18 уже работает! Я согласен, что в идеале он должен обрабатываться InteractionTracker, чтобы обеспечить бесперебойную работу даже во время загрузки потока пользовательского интерфейса.

@verelpode Оба режима установлены как «Должен». Так что, если усилия слишком велики для реализации режима 17, его можно просто исключить (и, возможно, добавить позже, если потребуется). Но, может быть, кто-то найдет способ реализовать это без особых изменений.

Я надеюсь, что в новом ScrollViewer есть возможность отключать или настраивать масштабирование с помощью клавиши «Ctrl».