Понимая что у людей разные вкусы, мы предусмотрели возможность переключения визуальных тем. На текущий момент у нас нет темы похожей на С1, но мы постараемся учесть ваше пожелание в будущих релизах.
Так же, мы предусмотрели механизм модификации встроенных тем. Процесс модификации описан тут
Такой длинный путь упихнули в одну статью. Надо больше подробностей. Как софт разрабатывали. Про деньги тоже интересно было бы почитать. Понятно, что там не обо всем можно рассказать..
У каждого человека как минимум одни девайс всегда под рукой и некоторое время каждый день уделяется на потребление контента. Действительно, сейчас есть огромная потребность в контенте. Проблема только в том, что люди выбирают какой то другой контент а не ваш. Нужно лучше думать как научить контент-завод генерить что то интересное.
Мне кажется, для успеха в этой схеме все равно должен быть человек - редактор. Который выбраковывает шлак, возможно дописвает что то за нейросеткой.
У нас в проекте есть проверка кодировки исходников. Она написала в виде analyzer'a . Если у исходного файла кодировка не utf8 bom, генертся ошибка. Сделали это потому что народ любит писать комментарии в коде на русском, а дефолтная кодировка нас не устраивала.
Так вот, когда мы пробовали вайбкрдинг, почти всегда ИИ ломал кодировку наших исходных файлов. Так что там много всяких подножек )
Конечно, нужно пробовать. Оценивать плюсы и минусы. Именно поэтому вендоры обычно дают большой триальный период. Например, у нас триал составляет 60 дней.
Такой срок мы закладываем на создание MVP. У всех требования разные и не всегда триал заканчивается покупкой.
Смотрите заголовок статьи ). Вам все равно придется что то делать с этим. В некоторых случаях можно накатить Линукс. В каких именно - надо смотреть и решать конкретно на месте. Конечно нужно учитывать умения админов принимая решение в пользу Линукс.
Каждый когда делает эти оценки затрат времени подразумевает какое-то конкретное рабочее место с каким-то набором софта. Поэтому мы вряд-ли сойдёмся в оценках. ))
Моя идея в следующем: там где переход на Линукс сильно накладный не делать его. А если например человек на рабочем месте только хром запускает, его производительность никак после миграции не изменится.
Если вы знакомы с winforms, то должны помнить что в них каждый контрол это отдельный хендл дочернего окна. Это системный ресурс который ограничен. На экране большой площади у вас может чаще возникать ситуация когда хендлов не хватает.
Винформс нужно оставить в прошлом.
Попробуйте наши демки. Мне ещё никто не жаловался что они тормозят. Все прекрасно работает. В том числе и на 4к
Windows однозначно более дружелюбна к зоопарку разного железа. Особенно если год выпуска железа примерно совпадает с жизненным циклом версии Windows, а вот если не совпадает ... то тогда линукс в помощь )).
У меня такая теория: если Linux правильно встал на ваше железо, он будет там работать стабильнее чем Windows и будет меньше всякого навязывать чего вы не просили его делать.
Дело в том, что затраты на создание Copilot просто несоизмеримы с затратами на такой плагин как решарпер и мы не знаем, насколько Copilot финансово успешен. Я бы не рискнул делать что то платное под VSCode
Если проект мертвый, то проще конечно его не трогать и как то запускать под wine.
Если проект нужно развивать, то для такого проекта созданного на 30 летней технологии должно совпасть несколько факторов: нужно найти собственника который готов вкладывать в проект на легаси, найти команду которая умеет и возьмётся разрабатывать винформс. Многие разработчики попробовав xaml платформы не возвращаются в винформс. Поэтому команду найти будет проблематично, но иногда такие проекты ещё встречаются.
Winforms очень устарел. Он создавался когда ещё были ЭЛТ мониторы. И разброс разрешений мониторов был небольшим. Сегодня программу могут запустить и на FHD мониторе и на широченном 8к. Winforms ни по производительности рендеринга ни по адаптируемости не вывезет это.
Не так давно появился XAML previewer экстеншен для VSCode. На мой взгляд, VSCode для NET в принципе не слишком удобный. Он создавался для веб разработки, а поддержку NET прикручивали к нему сбоку.
Бесплатность этого продукта сыграла с ним злую шутку: невозможно успешно продавать экстеншены к бесплатному продукту. Поэтому в экосистеме VSCode невозможен например Решарпер.
Предлагаю сойтись на мнении что нужно брать лучшее из обоих миров.
Давайте вспомним инфоповод к которому была написана статья. Окончание жизни Win10. Это значит что исправное железо которое стоит в офисе под столом или на столе у пользователя Microsoft предлагает вам выбросить. Есть вариант установить на него Linux и жить дальше спокойно. Разумеется, этот вариант подойдет не всем. Мы только говорим что есть такая возможность.
Спасибо что спросили. Попробую исправить ситуацию.
Если вы мигрируете с WinForms, будет сложнее. Потому что платформы идеологически сильно разные. Почти никто не делал WinForms приложения по MVVM паттерну. А это значит что в коде будет куча обработчиков сообщений которые придется переписать на команды во ViewModel. Еще миграция усложняется тем, что в винфоррмс можно было делать кастомную отрисовку. Этот код скорее всего придется выкидывать и переписывать на xaml стили. Но самая "нудятина" при миграции -: по огромной портянке в InitializeComponent понять что это такое, как оно должно работать. Вот с этой частью может помочь наш проект https://github.com/MICVGLOB/WinForms2AvaloniaConverter . Можно почитать в ридми и в исходниках как он работает. Если совсем коротко, он создаст xaml с Avalonia элементами UI которые функционально соответствуют и называются так же как элементы конвертируемой формы. Почти всегда за конвертером нужно подчищать лайаут, каким то элементам он не может найти прямых аналогов, но все равно он здорово нам сэкономил время когда мы мигрировали оргомный проект состоящий из более 300 форм на Avalonia.
Если мигрируете с WPF, будет проще. Однозначно сохранится слой ViewModel если приложение было написано правильно. Во View придется поискать аналоги некоторых элементов. Именование немного различается. Кастомизациия в XAML немного различается. В авлонии нет триггеров. Вместо них, есть система стилей.
Сложности, которые поджидают при миграции и с WinForms и с WPF: не используйте нигде пути в виде строковых констант. Лучше Path.Combine. Кодировки: если исходный код содержит русские символы, винда сохраняет такое обычно в своей кодировке. Мы конвертировали все в UTF-8 BOM и написали диагностики которые бьют по рукам тем кто пытается это соглашение нарушать. Environment.SpecialFolder в линуксах работают немного по другому. Читайте документацию. Винда игнорирует регистр в названиях файлов. Почти все, кто пытается впервые собрать свой проект под Linux, получают ошибки которые вызваны тем, что в csproj файл упомянут например MyClass.cs. А в папке лежит myclass.cs. Проблемы с клипбордом. Он на линуксах работает немного не так как как все привыкли. Проблемы с переводом строк. Например, если у вас будет sh файл с виндовым окончанием строк - CRLF, он ни за что не выполнится. Будут странные ошибки. Dos2Unix в помощь.
Вот, что сходу вспомнил ). Если вам будет нужна помощь с миграцией на Avalonia, напишите нам https://t.me/emxControls. Постараемся помочь.
По моему мнению, с Линукс меньше проблем чем с видной.
Правильно настроенный системник с Линукс скорее морально устареет чем сломается. А переустановка винды у многих пользователей довольно частая процедура.
Мне очень не нравится в современных виндах неотключаемая телеметрия, не отключаемый дефендер, некоторые настройки просто не работают или включаются назад сами. Привязка локальных учёток пользователей к облаку.
Спасибо. Посмотрим.
Понимая что у людей разные вкусы, мы предусмотрели возможность переключения визуальных тем. На текущий момент у нас нет темы похожей на С1, но мы постараемся учесть ваше пожелание в будущих релизах.
Так же, мы предусмотрели механизм модификации встроенных тем. Процесс модификации описан тут
https://eremexcontrols.net/controls/themes/modify-control-themes/
Исходники тем лежат на гитхаб
https://github.com/Eremex/controlthemes
Можно изменить любой визуальный аспект.
Такой длинный путь упихнули в одну статью. Надо больше подробностей. Как софт разрабатывали. Про деньги тоже интересно было бы почитать. Понятно, что там не обо всем можно рассказать..
У каждого человека как минимум одни девайс всегда под рукой и некоторое время каждый день уделяется на потребление контента. Действительно, сейчас есть огромная потребность в контенте. Проблема только в том, что люди выбирают какой то другой контент а не ваш. Нужно лучше думать как научить контент-завод генерить что то интересное.
Мне кажется, для успеха в этой схеме все равно должен быть человек - редактор. Который выбраковывает шлак, возможно дописвает что то за нейросеткой.
Красота. А можете порекомендовать проект чтобы рендерить 3д фракталы?
У нас в проекте есть проверка кодировки исходников. Она написала в виде analyzer'a . Если у исходного файла кодировка не utf8 bom, генертся ошибка. Сделали это потому что народ любит писать комментарии в коде на русском, а дефолтная кодировка нас не устраивала.
Так вот, когда мы пробовали вайбкрдинг, почти всегда ИИ ломал кодировку наших исходных файлов. Так что там много всяких подножек )
Конечно, нужно пробовать. Оценивать плюсы и минусы. Именно поэтому вендоры обычно дают большой триальный период. Например, у нас триал составляет 60 дней.
Такой срок мы закладываем на создание MVP. У всех требования разные и не всегда триал заканчивается покупкой.
У нас была статья с бенчмарками грида. Посмотрите у меня в профиле.
Смотрите заголовок статьи ). Вам все равно придется что то делать с этим. В некоторых случаях можно накатить Линукс. В каких именно - надо смотреть и решать конкретно на месте. Конечно нужно учитывать умения админов принимая решение в пользу Линукс.
Каждый когда делает эти оценки затрат времени подразумевает какое-то конкретное рабочее место с каким-то набором софта. Поэтому мы вряд-ли сойдёмся в оценках. ))
Моя идея в следующем: там где переход на Линукс сильно накладный не делать его. А если например человек на рабочем месте только хром запускает, его производительность никак после миграции не изменится.
Если вы знакомы с winforms, то должны помнить что в них каждый контрол это отдельный хендл дочернего окна. Это системный ресурс который ограничен. На экране большой площади у вас может чаще возникать ситуация когда хендлов не хватает.
Винформс нужно оставить в прошлом.
Попробуйте наши демки. Мне ещё никто не жаловался что они тормозят. Все прекрасно работает. В том числе и на 4к
https://github.com/Eremex/controls-demo
Там в релизах есть собранные бинарники под вин и под Линукс.
"IDEA комунити". Это из java мира. Не могу коментировать, не разбираюсь в их экосистеме.
Windows однозначно более дружелюбна к зоопарку разного железа. Особенно если год выпуска железа примерно совпадает с жизненным циклом версии Windows, а вот если не совпадает ... то тогда линукс в помощь )).
У меня такая теория: если Linux правильно встал на ваше железо, он будет там работать стабильнее чем Windows и будет меньше всякого навязывать чего вы не просили его делать.
Дело в том, что затраты на создание Copilot просто несоизмеримы с затратами на такой плагин как решарпер и мы не знаем, насколько Copilot финансово успешен. Я бы не рискнул делать что то платное под VSCode
Я имел ввиду не техническую сторону, а финансовую. Сложно предлагать платное там где люди не приучены платить.
Если проект мертвый, то проще конечно его не трогать и как то запускать под wine.
Если проект нужно развивать, то для такого проекта созданного на 30 летней технологии должно совпасть несколько факторов: нужно найти собственника который готов вкладывать в проект на легаси, найти команду которая умеет и возьмётся разрабатывать винформс. Многие разработчики попробовав xaml платформы не возвращаются в винформс. Поэтому команду найти будет проблематично, но иногда такие проекты ещё встречаются.
Winforms очень устарел. Он создавался когда ещё были ЭЛТ мониторы. И разброс разрешений мониторов был небольшим. Сегодня программу могут запустить и на FHD мониторе и на широченном 8к. Winforms ни по производительности рендеринга ни по адаптируемости не вывезет это.
Не так давно появился XAML previewer экстеншен для VSCode. На мой взгляд, VSCode для NET в принципе не слишком удобный. Он создавался для веб разработки, а поддержку NET прикручивали к нему сбоку.
Бесплатность этого продукта сыграла с ним злую шутку: невозможно успешно продавать экстеншены к бесплатному продукту. Поэтому в экосистеме VSCode невозможен например Решарпер.
Если я буду отвечать, получится прям холивар ).
Предлагаю сойтись на мнении что нужно брать лучшее из обоих миров.
Давайте вспомним инфоповод к которому была написана статья. Окончание жизни Win10. Это значит что исправное железо которое стоит в офисе под столом или на столе у пользователя Microsoft предлагает вам выбросить. Есть вариант установить на него Linux и жить дальше спокойно. Разумеется, этот вариант подойдет не всем. Мы только говорим что есть такая возможность.
Спасибо что спросили. Попробую исправить ситуацию.
Если вы мигрируете с WinForms, будет сложнее. Потому что платформы идеологически сильно разные. Почти никто не делал WinForms приложения по MVVM паттерну. А это значит что в коде будет куча обработчиков сообщений которые придется переписать на команды во ViewModel. Еще миграция усложняется тем, что в винфоррмс можно было делать кастомную отрисовку. Этот код скорее всего придется выкидывать и переписывать на xaml стили. Но самая "нудятина" при миграции -: по огромной портянке в InitializeComponent понять что это такое, как оно должно работать. Вот с этой частью может помочь наш проект https://github.com/MICVGLOB/WinForms2AvaloniaConverter . Можно почитать в ридми и в исходниках как он работает. Если совсем коротко, он создаст xaml с Avalonia элементами UI которые функционально соответствуют и называются так же как элементы конвертируемой формы. Почти всегда за конвертером нужно подчищать лайаут, каким то элементам он не может найти прямых аналогов, но все равно он здорово нам сэкономил время когда мы мигрировали оргомный проект состоящий из более 300 форм на Avalonia.
Если мигрируете с WPF, будет проще. Однозначно сохранится слой ViewModel если приложение было написано правильно. Во View придется поискать аналоги некоторых элементов. Именование немного различается. Кастомизациия в XAML немного различается. В авлонии нет триггеров. Вместо них, есть система стилей.
Сложности, которые поджидают при миграции и с WinForms и с WPF: не используйте нигде пути в виде строковых констант. Лучше Path.Combine. Кодировки: если исходный код содержит русские символы, винда сохраняет такое обычно в своей кодировке. Мы конвертировали все в UTF-8 BOM и написали диагностики которые бьют по рукам тем кто пытается это соглашение нарушать. Environment.SpecialFolder в линуксах работают немного по другому. Читайте документацию. Винда игнорирует регистр в названиях файлов. Почти все, кто пытается впервые собрать свой проект под Linux, получают ошибки которые вызваны тем, что в csproj файл упомянут например MyClass.cs. А в папке лежит myclass.cs. Проблемы с клипбордом. Он на линуксах работает немного не так как как все привыкли. Проблемы с переводом строк. Например, если у вас будет sh файл с виндовым окончанием строк - CRLF, он ни за что не выполнится. Будут странные ошибки. Dos2Unix в помощь.
Вот, что сходу вспомнил ). Если вам будет нужна помощь с миграцией на Avalonia, напишите нам https://t.me/emxControls. Постараемся помочь.
"почему надо выбирать именно вариант с линуксом."
По моему мнению, с Линукс меньше проблем чем с видной.
Правильно настроенный системник с Линукс скорее морально устареет чем сломается. А переустановка винды у многих пользователей довольно частая процедура.
Мне очень не нравится в современных виндах неотключаемая телеметрия, не отключаемый дефендер, некоторые настройки просто не работают или включаются назад сами. Привязка локальных учёток пользователей к облаку.