Здравствуйте, Философ, Вы писали:


P>>но и то и другое далеко не дотягивает до html-css-js

Ф>То, чего не хватало в XAML, легко дополнялось кодом на шарпе.

сейчас css/html работает автотматом в паралель в разных нитях,
это может иметь значение когда анимируются тысячи объектов одновременно,
имеется поддержка 3D WebGL
система версткии по своей идеологии близка к адобовкому pdf который стандарт в книгопечати-журналах-газетах-рекламных плакатах и тд
и он более интуитивен для гуманиариев-дизайнеров, намного легче им дается чем ксамл
большая часть динамики и анимации и изменени адаптаций к размерам делается без программирования
что также позволяет использовать дизайнеров вместо программеров
тз удобно формулировать в терминах книжной-журнальной верстки, что очень хорошо понимают гуманитарные дизайнеры
в частности встроена система единиц измерений принятая в книгопечати и гуманитарный дизайнер в ней ориентируется как рыба в воде
и никаких проблем с разными разрешеиями так как гуманитарный дизайнер постоянно печатает на разных принтера от 300 dpi до 6000 dpi
и вся эта проблематика с мониторами и телеками сверх-высокого разрешения и разных линейных размеров
для них вообще не проблема, они с этим постоянно сталкиваются в книгоиздании и эта "прошивка" у них уже в голове изначально.

Здравствуйте, paradok, Вы писали:

P>сейчас css/html работает автотматом в паралель в разных нитях,...3D WebGL

А в случае нативного гуя имеется "поддержка" нативных потоков и Direct2D/DirectX — не убедил. При этом я даже не знаю, сколько теоретически может быть потоков рендера в WPF — не видел больше одного.

P>и никаких проблем с разными разрешеиями так как гуманитарный дизайнер постоянно печатает на разных принтера от 300 dpi до 6000 dpi...

Сложности с DPI остались в WindowsForms, вот по этой причине.

P>....большая часть динамики и анимации и изменени адаптаций к размерам делается без программирования

Аналогично, взгляни.

Здравствуйте, Философ, Вы писали:


Ф>
>в WPF — не видел больше одного.

только в одном потоке.
3D только микрософта, в html — кросс-платформа


А такое есть в ксамл ?

1)CSS3 3D-трансформации объектов
2)Pica — a traditional unit of measurement used in print design + единицы измерения CSS: cqw, cqh, cqi, cqb, cqmax, cqmin
2)Разрывы между блоками для многостраничности: свойства break-before и break-after
3)Объединение и смешивание слоев
4)CSS Overflow содержит функции CSS для обработки прокручиваемого переполнения, отображаемого на визуальных носителях
5)Кернинг: свойство font-kerning
6)Лигатуры: свойство font-variant-ligatures

7)CSS3-фильтры воспроизводят в браузере визуальные эффекты, похожие на фильтры Photoshop. Фильтры можно добавлять не только к изображениям, но и к любым непустым элементам.
Набор фильтров не ограничивается предустановленными из коробки. Вы также можете использовать фильтры SVG, загрузив их по ссылке в реалтайм по сети.

8)media-запросы: автоматическая переключение аппаратно-зависимых таблиц стилей, позволившая создавать стили и таблицы стилей для определенных типов устройств
которые автоматически включаются и выключаются в зависимости от устройства, ай-фон, планшет, андроид, ТВ и тд. без участия программиста.

Здравствуйте, Философ, Вы писали:

и расcкажи плиз как на ксамлл решается такая задача желательно без программирования C#

например есть макет гуи( грубо говоря страницы) с текстом картинками кнопками таблицами графиками размером скажем 30 см на 15 см
т.е.на мониторе на столе фул аш-д со стула смотрится норм,
а теперь эту же прогу запускаем на тв приставке пусть даже на винде (такая есть у меня)
на экране 4к телека размером 55 дююймов по диагонали и смотрим на нее с 3-х метров

если вывести макет в прежних заданных в ксамл 30 см на 15 см то оа будет очень маленькой относитеьно оень большого экрана
и с 3-х метров ниего прочитатьь будет невзможно на ней

с помощью медиа-запросов css можно это исправить АВТОМАТИЧЕСКИ увеличив размер макета скажем до 120 см на 60 см и все будет видно.
Без программирования! Можно и на других размерах планшетах и тв запускать — все адаптируется автоматом
ли даже на планшее с портретнным режимом или на андроид и т.д.

ну я думаю в какой-то мере микрсофn дол;на была это порешать...
но не знаю есть ли в ксамл аналог медиа-запросов т.е. автоматического определения важных параметров экрана изменения как бы css стилей по него
без програминга на C#.
?

Здравствуйте, Философ, Вы писали:

и еще вопрос про ксамл

изменения ксамл требует ли перекомпиляции программы или как в случае html гуя он легко хранится отдельно в отдельном файле и его изменения не требуют перекомпиляции программы
?

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

конечно на C# можно сделать импорт нового гуя и там как-то програмно заменить старый... а вот без перекомпиляции проги средствами самого ксамл можно?

Здравствуйте, paradok, Вы писали:

P>а теперь эту же прогу запускаем на тв приставке пусть даже на винде (такая есть у меня)
P>на экране 4к телека размером 55 дююймов по диагонали и смотрим на нее с 3-х метров

Треть экрана будет занимать:

<Window 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    Height="{x:Static SystemParameters.PrimaryScreenHeight}/3" 
    Width="{x:Static SystemParameters.PrimaryScreenWidth}/3" />

На основе размеров окна (мы их уже в поинтах получим) можно получить относительные размеры остальных элементов. Так же несложно написать WPF хелпер, который будет возвращать всё, что знает GetSystemMetrics().

Ну а вообще, мелкософт на эту тему много чего понаписали. Когда я с этим возился, вот этого я ещё не видел.

Здравствуйте, Firstborn, Вы писали:

F>живут в броузере (из-за чего, например, конфликтов при совместной работе над таблицей там не бывает в принципе),

Office 365 уже отменили?

Здравствуйте, paradok, Вы писали:

P>изменения ксамл требует ли перекомпиляции программы...
P>конечно на C# можно сделать импорт нового гуя и там как-то програмно заменить старый... а вот без перекомпиляции проги средствами самого ксамл можно?

У нас требовали — никогда не задавался этим вопросом. Но теоретически это возможно:

var mainContent = XamlReader.Parse(@"<Button Width=""85"" Height=""35"" Content=""Test""
    xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
    xmlns:x = ""http://schemas.microsoft.com/winfx/2006/xaml"" />") as Button;
MainGrid.Children.Add(mainContent);

https://learn.microsoft.com/ru-ru/dotnet/api/system.windows.markup.xamlreader?view=windowsdesktop-7.0

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Office 365 уже отменили?

Не знаю. А должны были?

Здравствуйте, CreatorCray, Вы писали:

P>>https://cubiq.ru/brauzernye-igry/
CC>Что это за трэш?

Это браузерные игры. Пока что доля таких всего 2%
Ограничение в самом браузере, насколько я понимаю, дело даже не в перформансе. Пока что доминируют мобильные игры. Рано или поздно браузер подрастет и потеснит и десктоп, и мобайл.
Т.е. идет тот же процесс, что и в обычных приложениях, только медленнее.

Здравствуйте, Pauel, Вы писали:

P>Это браузерные игры. Пока что доля таких всего 2%

А откуда процент известен?

Здравствуйте, Pauel, Вы писали:

P>Это браузерные игры.
Это сложновато назвать полноценными играми.

Здравствуйте, CreatorCray, Вы писали:

P>>Это браузерные игры.
CC>Это сложновато назвать полноценными играми.

Наоборот. Для игры технологии как раз не важны.

Здравствуйте, Философ, Вы писали:

P>>Это браузерные игры. Пока что доля таких всего 2%

Ф>А откуда процент известен?

Заглянул в статью про состояние рынка игр.

Здравствуйте, Pauel, Вы писали:

Ф>>А откуда процент известен?
P>Заглянул в статью про состояние рынка игр.

А эта доля там в каких отношениях? В денежном? В количественном? Что-то другое?

Здравствуйте, Философ, Вы писали:

Ф>>>А откуда процент известен?
P>>Заглянул в статью про состояние рынка игр.

Ф>А эта доля там в каких отношениях? В денежном? В количественном? Что-то другое?

В денежном, млрд. Ссылки нет под рукой.

Здравствуйте, Философ, Вы писали:

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

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

касательно твоего компа мак 2019 — у тебя на нем сохранилась оригинальная эпловская операционка?
то скачай и установи FireFox for Mac — потестируй и расскажи тормозит ли он у тебя?
по моим набюдениям многие версии софта специально под Мак работают существенно быстрее чем на виндах
— это проверено на Unity (существенно быстрее), Visual studio -> Mono, Android Studio (весьма заметное ускорение), Эмулятор Android (очень сильно быстрее), FireFox
(хотя могут отставать по номеру версии)
P.S. у меня эмулятор андроида под мак работает быстрее реального железного samsung j7

Здравствуйте, paradok, Вы писали:

P>Здравствуйте, Baiker, Вы писали:


P>>>чувак тебе надо просто посмотреть адимнку американского генезиса (кол-центр)

B>> Что за "неоспоримые преимущества" даёт веб-страничка по сравнению с полноценным приложением на нативных контролах?

P>скорость!

Спасибо, поржал! Ещё шутки похожего уровня будут? Петросян спрашивал.


P> аналогичное изделие в предыдущей версии на C# на нативных контролах жутко тормозило

Вот уж бред бредовый! Так-то я догадываюсь, что просто наговнокодили индусы, но доп. подробности не помешали бы.

Когда у меня возникла аналогичная задача (миллионы записей, причём ещё и в иерархии!), тупо протестировал все варианты — несколько либ под ВыньФормс (включая хвалёные ДевЭкспрессы), несколько под WPF. Вердикт был чуть более, чем очевиден — всё г***но! А ввиду дебильной архитектуры WPF, решил написать кастомный контрол для ВыньФормс. И.... получилось! Скроллинг просто отменный, экспанд-коллапс, все дела. Причём ячейки — не хухры-мухры текстовые, а со всякими доп. символами, цветами-шрифтами и т.п.
Так что нет, чувак, аргументов у тебя нет — просто взять говноподелие и считать его за "тормознутую нативщину" — это надо вообще никакого инженерного мышления не иметь!


P>у нас критерий правильности — это высокая долговременная без усталости производительность операторов и админов.

Всё решается, веб тут вообще не причём.

P>серьезно повысил производительность труда и прибыль фирмы. Так что отправляем убогие нативные контролы на свалку истории или вообще на 3 буквы.

Ясно. Избави небо от таких "сотрудничков".

Здравствуйте, paradok, Вы писали:

B>> Что за "неоспоримые преимущества" даёт веб-страничка по сравнению с полноценным приложением на нативных контролах?
P>скорость!
Скорость чего? Наговнокоживания — может быть.

Здравствуйте, Sinclair, Вы писали:

S>Какая интересная была у вас ямаха. В наших паскаля не было, зато был встроенный бейсик. В головной машине — +встроенный графический редактор Paintbrush.

Бейсик был. А TurboPascal просто запускали с диска, а на Ямаха-2 было 128 Кб, и 64 из них отдавали под электронный диск. Физический дисковод был только на машине учителя, так что в начале занятия я им рассылал TurboPascal, раздавал их код, а в конце собирал обратно.