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

_>И мне вообще странно представить, что кто-то (ну естественно кроме авторов соответствующих библиотек) мог подумать об идее рисовать кнопочки руками — это уж слишком стандартная в индустрии задача, чтобы плодить свои велосипеды в прикладных приложениях, вместо использования готовых библиотек.

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

I>>Ну вебгл, и что с того?
I>>Само по себе это низкоуровневый движок рендеринга, без высокоуровневой либы ничего интересного не происходит.

_>Эммм, WebGL — это вообще не движок. ))) Это просто бальный доступ для твоего кода к видеокарте пользователя и всё.

Джижок, engine, это настолько широкий термин, что крайне странно к этому придираться.
API рендеринга вполне себе подходит под термин "движок"

_>И кстати, насчёт низкоуровневости. Мы используем в одном месте и непосредственно сам WebGL (да, те самые шейдеры, текстуры и т.п.), но не для прорисовки элементов GUI, а как раз для того, что ты называешь контентом (в нашем случае это специальным образом обработанное реалтаймовое видео). А уже поверх этого библиотечка рисует всякие свои всплывающие окошки с кнопками и т.п.

Все как я и говорил — экзотический случай, никаких шансов интеграции с другими системами/компонентами.

_>Вообще то я всего лишь отреагировал на твоё утверждение, что в браузере кроме как в DOM рендерить больше некуда. Как видишь есть куда, причём там ещё и в разы больше возможностей.

Тут надо только добавить, что я нигде такого не писал.

I>>Парадокс! И конечно же у тебя объяснение в том, что фронтенды они того, недалёкие, не знают своего щастя!

_>Но ведь судя по твоей цитате, вообще даже не знают о существование такой возможности!

Ты снова приписл мне абы что, читай сам:

На самом деле canvas UI кое где используется — там, где нужны в основном фукнкциональные элементы, часто нестандартные. Доля таких случаев крайне невелика. Как только появляется какой то контент, поверх канваса нарастает слой DOM. Типичные рисовалки так и сделаны — контент это дивы поверх канвасного слоя.

I>>Смешной аргумент. Сейчас 90% UI это бразерный на HTML/CSS/JS, а остальное примерно поравну делится межжу
I>>1. джава
I>>2. дотнет
I>>3. всякие иос и макос придумки
I>>и где то на грани статистической погрешности будут всякие QT

_>Web безусловно впереди, но совсем не из-за качества библиотек (тут скорее всё наоборот и мир фронтенда всегда был пугалом в остальном IT), а исключительно из-за другой (гораздо более удобной) схемы распространения и установки ПО.

Именно. А еще интеграция — любой крупный UI как правило сборная солянка частей от разных команд и даже вендоров. И это не редкость.

I>>Это значит, что вы занимаетесь узкоспециализированой работой, раз у вас не вожникают типичные для фронтенда задачи.

_>Просто слово фронтенд сейчас относят к любой веб-морде, будь то сайт-визитка или запускаемый в браузере CAD. Хотя это принципиально разные задачи, требующие абсолютно разных подходов. Заниматься украшательствами на сайтах — это действительно нормально. А вот заниматься таким же в приложениях...

Украшательства это твои 3д тени. А вот соответствие UX дизайну — это совсем другая вещь.

I>>Это или понты, или ложь — ну не бывает мгновенного набора текста. Вам присылают желаемую картинку, а вы должны вписать все шрифты, цвета, отступы, итд и тд.

_>Ой, да не цепляйся ты так по глупому к мелочам, сам же от этого смешно выглядишь. Думаю всем очевидно, что забить значения в подготовленные поля — это в контексте разработки означает мгновенное изменение.

Ога, перейти к респозив дизайну или сменить дизайн это совсем не "забить значения в подготовленые поля"
Лично у меня есть сомнение, что ваша либо позволит любо вариант дизайна применить за короткое время.
Любой — это значит вообще любой. Пришел новый дизайнер и начал ваять всё с нуля.

I>>Это же очевидно — при изменении ориентации UI должен выглядеть так, как решил дизайнер, а не так, как считает либа.
I>>И эти правила нужно описать.
_>Ты похоже или реально не знаешь как автоматически размещаются контролы во всех GUI библиотеках уже лет 15-20 или же просто придуриваешься. )))

В том то и проблема — устарело на 15-20 лет. Вы UX привязали к либе, а в реальном мире ровно наоборот — UX определяет вообще все.
Например, дизайнер показывает совсем другое размещение, при чем изменения будут под конкретного заказчика.
Твои действия? Будешь говорить дизайнеру, что ваша либа по другому не умеет?

_>Я правильно понимаю, что ты предлагаешь не трансформировать данные в свои прикладные типы, а использовать в приложение то, что выплюнет xml парсер?

Очевидно, что это не так Не надо никакой трансформации в свои прикладные типы. И использовать xml тоже не надо. Это устаревшие подходы.
Современный подход — UI определяет API и данные. Отсюда ясно, что избавляемся от лишних приседаний сравнивая UI 10 и 20 летней давности.
Схема взаимодействия проще, API проще, данные проще, стейтменеджмент гораздо более эффективный.

> Понятно, понятно... )))

Телепатия, однако.

> Ну да ладно, пускай даже так, это же у нас не реальная архитектура, а умозрительный пример на тему GUI. Так вот, не вижу никаких проблем в визуализации при таких данных. Просто делаем цикл по всем элементам, в котором для каждого xml узла добавляем его прорисовку, в зависимости от значения атрибута "тип" (в большинстве случае в виде просто одного соответствующего контрола из библиотечки). Могу за 20 секунд накидать код прямо форуме. ))) И где обещанная "страшная" сложность задачи? )))

Успокойся — xml это рудимент времен начала-конца нулевых.

I>> "доля ничтожна" означает "не прижился"
I>>А вот html/css/dom именно что прижился, т.к. его сейчас по скромной оценке процентов 90. На него переводят даже САПР, офис, итд. И даже в Микрософте. Вот так!

_>Ну как бы и фронтендеры в целом тогда тоже не прижились на этой планете, потому как их на порядки меньше таксистов...

Забавно, что ты съехал с темы. Речь то была про долю канвас UI во фронтенде.

Про такси — фронтендов не меньше чем таксистов. По крайней мере в нашей стране. И это при том, что такси у нас довольно популярная профессия.
На самом деле ёмкость рынка труда в такси гораздо ниже емкости рынка труда в IT.
Это никакой не парадокс — рынок IT растет очень быстро и значительная часть этого роста это тот самый фронтенд. А вот такси не растет нисколько, количество машин привязано к средней ЗП в стране и количеству населения. Тут ситуация меняется крайн слабо.