Freedom to change

[vitus_wagner]

Вот смотрю я на развитие проекта Devuan и думаю, что форк без systemd это, конечно, благая идея. Но если не отказаться от GTK и Qt, создать систему в которой от использования GUI будет легко перейти к его модификации, не получится.

Comments

[tzirechnoy.livejournal.com]

И да, в DOM HTML+DOM CSS с этим, кстати, относительно неплохо. Чуть ли не лучшэ, чем в tcl/tk.

[vitus_wagner]

НУ если оттуда выкинуть собственно HTML...

Но прежде чем взять это за основу, надо понять почему Chrome OS, Firefox OS и пальмовская WebOS не выстрелили. Ведь призрак html+css-based desktop бродит по миру почти как призрак коммунизма сто лет назад, чуть ли не с начала века.

[eldhenn]

Раньше. Active Desktop появился в Мемфисе, вернее, в IE4.

[brmail]

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

[vitus_wagner]

Софт, которому нужны какие-то "производители" идет лесом.

[brmail]

а-а-а, ясно. тогда почему у тебя на столе не сплошняком хромбуки?

[alexyecu.livejournal.com]

Потому что ХромОсь примером «софта, которому не нужны производители» не является, да ещё и ущербней со всех сторон ущербного Андроида?

[brmail]

зачем тогда задавать вопрос "почему не взлетела"

[justy-tylor.livejournal.com]

Почему не взлетает - HTML изначально делался под "тексты без стилей, но со ссылочками", и возможность делать UI там сильно сбоку, вечно вылезает legacy. Проблем добавляет DOM, где неграмотные люди стандартизировали такой механизм апдейтов, чтобы всё тормозило и нещадно кушалась батарейка.

Несколько лучше в SVG, но там сохраняются проблемы DOM, а также отсутствует text layout.

Для качественной реализации нужно хорошее дерево сцены (без недостатков DOM) и возможность использовать встроенные layout-алгоритмы для текстов. Всё остальное (включая layout для блоков, логику data binding, etc) прекрасно делается скриптом.

[vitus_wagner]

Это уже очень интересно. Чувствуется что у вас не первый подход к этому снаряду.

Вы рендеринг текста в word-процессоре включаете в ту часть фукнционалдьности. которую должна обеспечивать UI-подсистема операционки, или это все-таки уже относится к функциональности прикладной программы, которая получает что-то вроде канвы и может там рисовать что угодно попиксельно?

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

layout блоков - он, понятно, нужен в любом интерфейсе. Если вы не предложите других примитивов из которых собирать диалоговые окна настроек, меню и т.д. layout текстовых абзацев, на мой взгляд, встречается несколько реже, хотя, возможно, зря. Возможность писать развернутые комментарии к элементам UI может и не вредна.

[justy-tylor.livejournal.com]

Text layout and rendering - сами по себе достаточно сложные предметные области, и если фреймворк их не умеет из коробки, то его полезность сомнительна. Самое разумное - поддержать разные режимы. И пакетное "вписать текст в геометрию", и "позиции вычисляются из метрик пользовательским кодом, но рендеринг стандартный", и полностью custom draw решение (например, при визуализации PDF-документа). При этом, immediate mode API такой отрисовки может дословно соответствовать retained mode API построения дерева сцены.

А вот наборы standard controls и standard sizers можно предложить библиотечкой на выбранном скрипте. Легко использовать, легко кастомизировать.

Ранее я занимался этими темами в LG. И отдельный SVG-движок, и внутренние фреймворки/редакторы UI. Но там тоже было не всё из вышеуказанного.

[vitus_wagner]

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

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

Что касается "выбранного скрипта", то тут предвижу большую засаду, под названием "многоязыковое программирование". Все-таки десктопная ОС это не телефон. Под нее есть разные задачи, которые удобно решать на разных языках. В свое время авторы питоновского Tkinter пытались решить задачу "разрешить в GUI python-а использовать скриптовые библиотеки Tcl". Результат как-то не очень впечатлял.

Есть, конечно, надежда, что можно сформировать стэк языков, так чтобы на любую задачу нашелся более-менее подходящий, и при этом решение задачи всегда выглядело как написание компоненты для использования из скрипта более высокого уровня. Ну вроде того как пишут на C, Python etc программы, которые используются как операторы языка shell. Но вот слабая это надежда, что на том уровне где в основном будут плодится библиотеки виджетов, удастся обойтись одним языком.

[justy-tylor.livejournal.com]

Возможен интероп (wxWidgets и Qt представлены для многих языков). Причём, если дизайн API сильно data driven, то это делается проще, чем в случае упомянутых тулкитов.

Также, юные фанаты очередного хипстеркоболскрипта могут сами делать обёртки и библиотеки, ради самореализации или ещё чего-то там внутритусовочного.

[tzirechnoy.livejournal.com]

> что-то вроде канвы и может там рисовать что угодно попиксельно?

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

[vitus_wagner]

Из какого такого обихода? Где-то я недавно читал про тулкит, у которого все коордитнаты вещественные, и о том какими извращениями там приходится заниматься программистам, чтобы избежать размытия и замыливания объектов.

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

[tzirechnoy.livejournal.com]

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

Да вроде где-то в этом трэдике было.

На самом деле, одно с другим не имеет никакой связи. Совсем. Вещественные координаты у нас, кроме WPF, в postscript и OpenGL. В последних двух ничего особенно не замыливается (точнее, надо спецыально постараться, чтобы замыливалось).
А замыливается -- в HTML5 canvas, где координаты исключительно цэлочисленные.

И зависит это, конечно, от рук тех, кто писал рендэрер, а не от чего-то ещё.

[vitus_wagner]

Перечитай еще раз заголовок поста. Там написано Freedom to change. Все что угодно, в том числе и рендерер.

[tzirechnoy.livejournal.com]

"Папа, а ты с кем сейчас разговаривал?" (c)

[anonim-legion.livejournal.com]

А что вы можете сказать про WPF?

[justy-tylor.livejournal.com]

Концептуально намного более продвинут, чем остальные публично известные фреймворки. Это и attached properties, и чёткая модель Measure/Arrange/Render с соответствующими Affects* флажками, и data binding.

Но реализация подкачала:
1. Проблемы с имплементацией координатной системы на float, необходимость ручных действий для избегания "мыла" и субпиксельных расхождений.
2. Очень неэффективная (медленная) отрисовка. Причём, на верхнем уровне всё ок и можно сделать правильно, проблема только в низкоуровневой прокладке над вызовами драйверов, которую за всё это время так и не переписали.
3. Плохо вписывается в возможности C#, что провоцирует обилие boilerplate кода и общую тяжеловесность решений. Для таких идей язык надо либо менять, либо развивать (что, например, сделали с C# авторы LINQ).
4. Бестолковый пайплайн разработки с ручным редактированием нечитаемых XML (XAML-описаний).

[allter]

Что значит, "не выстрелили". Для узких применений Chrome OS, насколько я понял, работает.
Но с DOM+CSS-рендерингом проблема в том, что сложные диалоги (с развесистыми таблицами) в лоб очень тормозят, а делать всякие хитрые манипуляции с DOM на лету требуется квалификация от программиста, сравнимая с квалификацией MFC/Qt программистов.

А пользователи максимум, с текстом могут поработать; от графических приложений им в данное время требуется лишь качественная не очень тормозная работа без какой-либо гибкости.

[shadowfoto.livejournal.com]

в хромоси и фф разве можно что-то делать оффлайново?

а с вебос вроде маркетинговый отдел "постарался" на пару расстрелов и одно утопление в деревенском нужнике.