Windowscommunitytoolkit: Как я могу обрабатывать MasterDetail Back с помощью NavigationView BackButton?

@skendrot может помочь здесь

кажется, @skendrot занят, может кто-нибудь еще взглянет на него? @nmetulev ?

Привет, был в отпуске, спасибо за дополнительный пинг. Я не думаю, что в настоящее время мы справляемся с этим, но мы говорим об этом. Мы говорили о способе просто отключить отображение / скрытие / с помощью системной кнопки возврата. Но я также мог видеть, что, возможно, мы могли бы интегрироваться и с новым видом навигации.
Что вы думаете о следующем:

• По умолчанию используется системная кнопка возврата. Если новое представление навигации присутствует, используйте его вместо
• Есть возможность полностью отключить кнопку "Назад" и позволить разработчику решить, как с этим поступать.

У нас также может быть перечисление для управления кнопкой возврата
Система, NavigationView, Выкл.

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

как насчет наличия перечисления для этого, а также отключения кнопки возврата системы по умолчанию, а затем разработчики могут включить ее, если захотят? Потому что новая навигация по кнопке «Назад» в NavigationView поощряется в будущих документах.

ИМО, это приведет к изменению поведения существующих пользователей, если мы не сможем обнаружить новое представление навигации. @skendrot , как ты думаешь?

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

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

да Параметры @skendrot всегда гибкие, и их всегда полезно иметь, особенно при крупном переходе. Так как же теперь этому двигаться вперед?

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

1. Используйте стандартную кнопку "Назад" и "загорание", если новое представление навигации доступно, И предложите способ полностью отключить кнопку "Назад".
2. Предложите новую опцию перечисления, которая позволяет разработчику выбирать между стандартной кнопкой возврата, кнопкой перехода назад и выключением

Проголосуйте 👍 за 1 и 🎉 за 2

Я бы объединил эти два и использовал перечисление для управления подсветкой кнопки «Назад», предоставив три значения:

• Автоматически - по умолчанию (он самостоятельно определяет, как обрабатывать обратную навигацию)
• Наследие
• Выключенный

Я бы посоветовал вам вместо Automatic, Legacy и Off указать параметры перечисления, которые ясно показывают, что они будут делать. Например

BackButtonBehaviour:

• DisplayInline
• UseExternal
• Назад

DisplayInline будет использоваться по умолчанию в соответствии с инструкциями по отображению стандартной кнопки возврата в элементе управления. Это также может работать с кнопкой B на геймпаде или клавишей Backspace на клавиатуре, когда элемент управления находится в фокусе.

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

BackDisabled полностью отключит обратную навигацию.

Разработчики и проекты, такие как Template 10, могут затем создать страницу или страницу шаблона с настройками, которые позволяют им управлять использованием кнопки «Назад».

Согласитесь с @mdtauk!

@mdtauk да, определенно это предложение имеет больше смысла и кажется более

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

Однако мы также должны обеспечить автоматическую обработку кнопки возврата NavigationView. Я не думаю, что имеет смысл отключать и обратную навигацию, это должно быть то, с чем должен работать пользователь.

Вот мое обновленное предложение

Перечисление: BackButtonHandling

• Автоматически (по умолчанию) - использует встроенную кнопку, если NavigationView не является родительским, а затем используйте навигацию NavigationView назад

• Встроенный - используйте встроенную кнопку

• Legacy - необходимо убедиться, что мы поддерживаем кнопку возврата оболочки для тех разработчиков, которые еще не отказались от нее.

• Вручную - позвольте пользователю нарисовать собственную кнопку возврата и делать это так, как ему хочется.

Вместо Legacy как насчет System или SystemAppViewBackButton или AppView или чего-то еще

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

Система мне нравится больше, чем наследие, это намного лучше

В любом случае я не особо сожалею о значениях по умолчанию, поскольку следующая версия - это крупное обновление (5.0). Я согласен оставить его по умолчанию на System, а затем изменить значение по умолчанию на Automatic в 6.0.

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

Вероятно, мы не будем отказываться от использования кнопки «Назад» до тех пор, пока она не будет удалена из платформы.

Даже с Set, системная кнопка возврата не устарела. Он просто поместит его на панель под вкладками с кнопкой «Назад». Но если есть Set, вам обязательно нужно переключиться на кнопку в приложении

Правильно, я должен уточнить: мы должны отказаться от опции из перечисления только в том случае, если она также будет исключена из платформы (я не думаю, что есть какие-либо планы сделать это)

так что, по-видимому, есть целая панель инструментов только для 1 кнопки возврата (в случае наборов)? или на нем будет больше элементов управления платформой?

так что, по-видимому, есть целая панель инструментов только для 1 кнопки возврата (в случае наборов)? или на нем будет больше элементов управления платформой?

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

Если задуматься, кнопка «Назад» находится в пределах вкладки «Наборы». Он не отображается рядом с вкладками и поэтому не может отображаться в строке заголовка.

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

@touseefbsb На данный момент это стандартное поведение, если вы разрешите оболочке обрабатывать кнопку «Назад» с окном «Наборы». Поскольку наборы по-прежнему не включены в сборки Windows, это может измениться, но лучше разрешить оболочке элемента управления / приложения обрабатывать рисование кнопки возврата и отказаться от того, чтобы заголовок обрабатывал ее.

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

Наборы могут даже не попасть в выпуск 19H1, поэтому на данный момент важно, чтобы приложения выглядели хорошо и по возможности расширялись в заголовки. Разработчики также могут запретить своему приложению работать с наборами, поэтому имеет смысл иметь гибкость с элементом управления и изменять / переопределять значения по умолчанию при запуске на вкладке «Наборы». По крайней мере, мне нравится, лол

@mdtauk, если разработчики

@touseefbsb Я так понимаю. При открытии из другой вкладки он появится в собственном окне, и его нельзя будет сохранить вместе с другими вкладками.

Небольшое усложнение для поддержки нового NavigationView. Обработчик события BackRequested не содержит способа отменить событие или отметить, что оно было обработано. Без этой возможности MasterDetailsView обрабатывал бы переход от подробных представлений к основным представлениям, а затем разработчик также справился бы с возвратом в состояние.
Мы можем поддерживать IFF, фрейм также используется для облегчения навигации.

@mvegaca , вы используете фрейм для размещения

Мы уже обрабатываем навигацию по фреймам, так что она уже встроена. Мы просто не можем полагаться на использование нового NavigationView, если также нет фрейма.

Итак, если WTS использует фрейм для навигации внутри NavView, он уже должен работать?

Да, с ненужными дополнениями. MasterDetailsView активирует кнопку возврата системы, чего не требует WTS. Но если они обрабатывают кнопку возврата NavigationView, перемещаясь по фрейму, то MasterDetailsView перехватит это событие, и, если это свернутое состояние Details, пометит его как отмену и вернется к основному представлению.

Мы (WTS) используем фрейм внутри NavView. Кнопка возврата navview уже работает, но отображается дополнительная кнопка возврата системы. Чтобы обрабатывать обратную навигацию, мы используем Frame.GoBack, но наша проблема - это системная кнопка возврата, показанная перед возвратом. Так что я не уверен, что мы в порядке. Есть ли способ это проверить?

Да, это проблема, которую решает PR

Привет, @nmetulev. Я пытаюсь протестировать новый BackButtonBehaviorProperty в клоне репозитория git @skendrot, но я не могу скомпилировать приложение, ориентированное непосредственно на библиотеку.
Можете ли вы утвердить PR для тестирования этих изменений в пакетах MyGet CI?

Спасибо

@mvegaca У меня была такая же проблема при попытке протестировать. Я не мог сослаться на свою локальную копию сборок. Нам нужно выяснить, что здесь происходит, потому что это значительно усложняет тестирование.

Какие проблемы у вас возникают при тестировании сборок?

Мы добавили приложение PoC в решение WCT, удалили ссылку на пакет nuget и ссылку непосредственно на проекты.
Когда я компилирую проект, я получил следующую ошибку во всех файлах XAML:

xml C:\dev\skendrot\UWPCommunityToolkit\Issue2475PoC\Issue2475PoC.csproj : XamlCompiler error WMC1013: XAML files 'App.xaml' and 'App.xaml' have the same project path 'App.xaml'. Each file must have a unique project path.

Это также происходит, если я добавляю в решение новое пустое приложение UWP App1.
xml XAML files 'App.xaml' and 'App.xaml' have the same project path 'App.xaml'. Each file must have a unique project path. App1 C:\dev\skendrot\UWPCommunityToolkit\App1\App1.csproj

Спасибо @nmetulev ;)

Я рекомендую создавать nugets локально и ссылаться на них. Вы можете сделать это с помощью сценария build\build.ps1 который должен генерировать объекты в папке bin.

@mvegaca Те же проблемы, что и я

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

Мы протестировали его локально, он работает нормально 😄
Можете слить PR, если вас все устраивает.

Спасибо всем, ребята

PR объединены

Привет @nmetulev

Я пытался использовать его в предварительной версии 5.0.0-preview.gb86cb1c4cb, но свойство BackButtonBehavior недоступно.

Как вы думаете, когда это исправление будет доступно в предварительной версии и будет доступно в стабильной версии?

Спасибо

Да, он будет доступен в версии 5.0.0 на следующей неделе. Он также доступен в предварительном выпуске на MyGet: https://dotnet.myget.org/gallery/uwpcommunitytoolkit