В простом пролетарском WPF определения Style помещают в Window.Resources. Авалония стили отделила от ресурсов. А вот селекторы в стилях - это уже чисто на авалонском. Для единообразия попробуйте вместо них использовать <Style.Triggers>
Да, конечно. Это тоже вполне работающий вариант, хотя и не привычный.
По моему, при таком подходе (определение иконок в ресурсах) вместо <Canvas> предпочтительнее использовать <Image>. Как минимум, для тех кто ранее использовал растровые иконки это будет привычнее (для них тоже принято использовать <Image>).
Попробуйте такой вариант определения иконки в ресурсах (на примере «record2.svg»):
Спасибо, правильный вопрос. Я даже это объяснял в статье, но потом вырезал (и так объемно получилось).
Основной мотив: не хотелось просаживать рендеринг (на сотнях элементов становится заметно). Кроме того, из личного опыта - редко требовалось более 2-х цветов (для иконок в меню, тулбале, сайдбаре, гриде). Речь не идет о многоцветных логотипах, для этого можно использовать, например, сложную геометрию в XAML-ресурсе.
Обычно один цвет нужен для привлечения внимания (красный, желтый) и повышения узнаваемости (брэнд-колор).
Второй цвет полезен, чтобы меньше промахивались: по иконкам 16x16 можно не отличить команды "Удалить запись" от "Добавить запись" (наличие красного дает больше шансов).
Попробуйте такой вариант (конвертация SVG в XAML). Мне кажется у него есть некоторые преимущества. Для простоты здесь "DrawingImage" помещен в локальные ресурсы, но на практике их принято держать в отдельном файле, например, "Resources/Icons.axaml".
Статья имеет тип "Туториал", название начинается с "Создание контрола". Т.е., по определению, статья ориентирована на тех, кто учится или уже создает "свои велосипеды" (собственные контролы).
Я не очень понял зачем это все?
Нет, ответа там нет, потому я и задал его.
В пункте "Почему именно Bootstrap Icons?" я постарался обосновать, что не надо "изобретать велосипед" и рисовать свои иконки. Извините, если у меня это не получилось.
Bootstrap (и позже появившийся Bootstrap Icons) являются для веб-разработчиков стандартом де-факто. Мне кажется, попробовать перетащить Bootstrap Icons из мира веб в Avalonia будет не лишним.
Согласен, при помощи класса тоже хороший вариант. Для моей реализации подсказки в дизайнере Visual Studio тоже работают, причем без {x:Static} и, что удивительно, даже namespace не надо указывать.
upd: Компилятор тоже не даст указать несуществующую айконку.
Это один из вариантов хранения в C#-коде, когда всё в одном месте (обозримость, легкая правка). Для меня было главное - уйти от ресурсов в XAML и как-то автоматизировать включение фрагментов SVG-файла в свой код. Возможно, не самый оптимальный вариант. Что можете предложить взамен?
Спасибо за пример. Хорошая заготовка.
Приложение даже запустилось без проблем.
Только версии NPM-пакетов очень старые.
Подтягивание dot.net core до версии 2.1 прошло нормально.
Но перейти на свежий webpack не получилось — не хватает образования.
Попытка подтянуть версию Vue.js тоже сходу не проходит (ошибки компиляции TypeScript).
Официальный стайл-гайд требует, чтобы для фреймворка явно описывались типы свойств компонента. У вас — массив. Исправляем, делаем явно — и получаем дубликат описаний, то есть еще хуже.
Массив использовать опасно ещё по одной причине — у компилятора TypeScript частично отключается контроль типов.
Теоретически оба варианта определения props, которые приведены ниже, должны работать одинаково. И это действительно так. Даже получаемый на выходе JavaScript код одинаковый.
Но обнаруживается неприятный баг-фича в тайпинге Vue.js.
Если props определены как массив, то для компилятора TypeScript перечисленные свойства становятся легальными.
Например, компилятор спокойно скушает использование this.filterKey.
Перечисленные в props свойства даже в IntelliSense появляются при использовании VS2017.
А если определить props явно с указанием типов, то компилятор будет материться на тот же this.filterKey.
Версия тестового приложения для WPF немного отличается определением стиля и его использованием.
Чтобы получить работающее тестовое приложение для WPF, выполните в терминале команду:
Затем замените текст
MainWindow.xaml
:Скрытый текст
Если требуются изменять размеры иконок, то
<Image>
надо обернуть во<Viewbox>
. Также для удобства ввел класс для стилизацииbi
(bootstrap icon).Чтобы получить работающее тестовое приложение для Avalonia, выполните в терминале команду:
Затем замените текст
MainWindow.axaml
:Скрытый текст
В простом пролетарском WPF определения
Style
помещают вWindow.Resources
. Авалония стили отделила от ресурсов. А вот селекторы в стилях - это уже чисто на авалонском. Для единообразия попробуйте вместо них использовать<Style.Triggers>
Забыл добавить
Stretch="None"
Да, конечно. Это тоже вполне работающий вариант, хотя и не привычный.
По моему, при таком подходе (определение иконок в ресурсах) вместо
<Canvas>
предпочтительнее использовать<Image>
. Как минимум, для тех кто ранее использовал растровые иконки это будет привычнее (для них тоже принято использовать<Image>
).Попробуйте такой вариант определения иконки в ресурсах (на примере «record2.svg»):
Чтобы отличать запрещенную кнопку, возможно, такой вариант изменения
Opacity
будет проще:В таком случае ваш пример использования иконки можно превратить в нечто подобное:
Исправленный вариант (кроме ширины у "align-top" ещё смещение вверх было):
Спасибо, поправлю. Мне его ИИ перерисовывал. Надо было проверять тщательнее.
Спасибо, правильный вопрос. Я даже это объяснял в статье, но потом вырезал (и так объемно получилось).
Основной мотив: не хотелось просаживать рендеринг (на сотнях элементов становится заметно). Кроме того, из личного опыта - редко требовалось более 2-х цветов (для иконок в меню, тулбале, сайдбаре, гриде). Речь не идет о многоцветных логотипах, для этого можно использовать, например, сложную геометрию в XAML-ресурсе.
Обычно один цвет нужен для привлечения внимания (красный, желтый) и повышения узнаваемости (брэнд-колор).
Второй цвет полезен, чтобы меньше промахивались: по иконкам 16x16 можно не отличить команды "Удалить запись" от "Добавить запись" (наличие красного дает больше шансов).
Попробуйте такой вариант (конвертация SVG в XAML). Мне кажется у него есть некоторые преимущества. Для простоты здесь "DrawingImage" помещен в локальные ресурсы, но на практике их принято держать в отдельном файле, например, "Resources/Icons.axaml".
Спасибо. Хороший пример для тех, кто собирается научится использовать эту библиотеку.
Но ведь название статьи "Создание контрола Avalonia/WPF для двухцветных векторных Bootstrap Icons".
Статья имеет тип "Туториал", название начинается с "Создание контрола". Т.е., по определению, статья ориентирована на тех, кто учится или уже создает "свои велосипеды" (собственные контролы).
В пункте "Почему именно Bootstrap Icons?" я постарался обосновать, что не надо "изобретать велосипед" и рисовать свои иконки.
Извините, если у меня это не получилось.
Bootstrap (и позже появившийся Bootstrap Icons) являются для веб-разработчиков стандартом де-факто. Мне кажется, попробовать перетащить Bootstrap Icons из мира веб в Avalonia будет не лишним.
Чего придираетесь? Еду как могу...
ПыСы: Обновил текст статьи, сделал замену: "айкон" -> "икон".
Ответ на ваш вопрос есть в первых двух разделах статьи. Из наиболее существенного для предлагаемого нами подхода:
за нас команда Bootstrap почти всё нарисовала, можно обойтись без дизайнера;
можно относительно легко добавить немного цвета, что-то подправить, дополнить;
увеличение затрат на рендеринг минимальное (штатные <Path> + <Viewbox> работают прекрасно для Avalonia и WPF);
альтернатива хранения ресурсов в XAML/AXAML (нет зависимости от Avalonia/WPF).
This package has been deprecated.
Наверно вы имели ввиду Svg.Skia, который здесь в комментариях уже упоминали.
В любом случае: Зачем нам лишняя зависимость от внешней библиотеки в production?
Кроме того, увеличиваем углеродный след приложения (конвертация SVG в runtime - самый энергозатратный и тормозной для UI вариант).
Спасибо, посмотрю как они это реализовали. Только для нашего случая, наверно, будет тяжеловато. И по рендерингу, и по программной реализации.
Абсолютно точно, именно эти 4 штуки мне кровь портили.
Поэтому я в своем генераторе их переопределяю.
Результат работы генератора:
PS: простите за мой француcкий, проверявший меня на ошибки и опечатки ИИ не ругался.
А это как сделать в Avalonia?
Согласен, при помощи класса тоже хороший вариант. Для моей реализации подсказки в дизайнере Visual Studio тоже работают, причем без
{x:Static}
и, что удивительно, даже namespace не надо указывать.upd: Компилятор тоже не даст указать несуществующую айконку.
Это один из вариантов хранения в C#-коде, когда всё в одном месте (обозримость, легкая правка). Для меня было главное - уйти от ресурсов в XAML и как-то автоматизировать включение фрагментов SVG-файла в свой код. Возможно, не самый оптимальный вариант. Что можете предложить взамен?
Приложение даже запустилось без проблем.
Только версии NPM-пакетов очень старые.
Подтягивание dot.net core до версии 2.1 прошло нормально.
Но перейти на свежий webpack не получилось — не хватает образования.
Попытка подтянуть версию Vue.js тоже сходу не проходит (ошибки компиляции TypeScript).
Массив использовать опасно ещё по одной причине — у компилятора TypeScript частично отключается контроль типов.
Теоретически оба варианта определения
props
, которые приведены ниже, должны работать одинаково. И это действительно так. Даже получаемый на выходе JavaScript код одинаковый.Но обнаруживается неприятный баг-фича в тайпинге Vue.js.
Если
props
определены как массив, то для компилятора TypeScript перечисленные свойства становятся легальными.Например, компилятор спокойно скушает использование
this.filterKey
.Перечисленные в
props
свойства даже в IntelliSense появляются при использовании VS2017.А если определить
props
явно с указанием типов, то компилятор будет материться на тот жеthis.filterKey
.Вот такой баг-фича.