[HTTP][!HTML][Qt] А что если...

http://labs.trolltech.com/blogs/category/labs/lighthouse/

Хотел дописать в конце сообщения:
«Может есть уже такие проекты?»
Думал что твоя ссылка как-раз на такой проект. Увы, нет. Но очень и очень любопытно, да. Из этой ссылки я даже могу выделить ещё один профит: возможность нормального создания веб-ос на qt с лайтхаус.

Идея конечно хорошая. Давно уже витает в воздухе. Ибо зачастую проще написать с нуля чем насиловать труп.

Витает то понятно. Но почему все огрничиваются рамками браузера? Почему все(«тролли», на самом деле обычные дураки; месяц назад один человек с пеной у рта так говорил) считают что веб это html?
Теоретически, это просто реализовать. Проще чем браузеры. Но во тя не могу понять почему никто до сих пор не сделал.
Неужто все так узко мыслят?

п.1. Скоро на экранах. Internet Explorer. Технологии будущего. Всего через 740 лет.

Вообще мысль очень хорошая. Именно в рамках Qt очень хорошо реализуемая. (qt-declarative + qt-kinetic для eye-candy, например).

XHTML изобрел?

+700. Правильная идея.

.ui вроде не xml, но это не важно.

На QML можно стоить красивые современные веб-морды (ну только теоритически)

> +700. Правильная идея.

Еще один школьник в треде?

На QML можно стоить красивые современные веб-морды (ну только теоритически)

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

Будь анонимус чуть более внимательный, он бы заметил что сходства с xhtml здесь - 0.

>о проблемах с безопасностью
QML-код имеет доступ только к себе. Если и есть возможность сделать что-то небезопасное, то всегда можно защитить это просто проверкой QML-файла.

компиляцией этого всего добра

Ах. Видимо, ты не понял что такое QML и в чём моя идея.

необходимости отображения страниц на разноформатных устройствах

Это просто как 2 пальца. Вот браузер используют на разных устройствах? Вот та же система и здесь.

>Другая проблема что нужно будет сделать специальный qt-дизайнер(или допилить этот, или добавить виджетов) для некоторых задач, что в вебе есть а в кути обычными виджетами сделать не очень просто.

И ты получишь html. Ну или xhtml. Язык разметки, где определённому тэгу соответствует некоторое определённое отображение в виде виджета на кути. По сути браузер на кути - уже то, что ты хочешь, просто «виджеты» отрисовывает не так:)

Не очень понятне смысл, так как:

Фактически, получится что можно использовать любой веб-фреймворк и движок темплейтов для написания кода для браузера. Т.е. на стороне сервера изменений нет, а вот клиент - да, очень преобразится.

Напиши браузер на кути, который меняет <input> на виджет со строкой на кути и получишь то же самое. Далее:

Накидать GUI на Qt проще чем на html.

Проще потому что

1) html староват и для совместимости его оставляли таким, какой он есть, а на момент создания он был адекватен,

2) потому что на html уже есть разница в отрисовке в разных браузерах, а на кути пока нет. Вот сделаешь ты эту штуку, а альтернативно одарённые сделают в IE-ng-edition отображение через виндовый тулкит. И привет совместимости - мы пришли к html заново.

К чему это я. Да к тому что надоели все эти войны о WPF, Сильверлайт/Мунлайт, Моно, HTML5, JS, Java.

Ну так войны не кончатся. Каждая из приведённых технологий и есть попытка сделать универсальное добро для всех. Так что твоя идея о Qt-html ничем не отличается от JavaFX по своей сути.

Если ты найдешь способ заставить всех использовать одну технологию, то тогда и html-я хватит.

>И ты получишь html. Ну или xhtml.
Если сказать что xhtml это просто язык разметки, то да. Однако, я хочу не просто язык разметки, а язык разметки и логики(QML как-раз то что нужно!). При этом чтобы он был стандартизирован в рамках одного фреймворка и не имел вольной реализации.
Грубо говоря, это идея создания языка разметки с нуля, но используя готовую платформу. Это стабилизирует как сам язык, апи и остальное, так и браузеры(которые нужно будет делать).

Язык разметки, где определённому тэгу соответствует некоторое определённое отображение

Это любой язык разметки. Не только XML, QML, HTML.

По сути браузер на кути - уже то, что ты хочешь

Не совсем. Браузеры что существуют сейчас(движки, точнее) парсят ужасный код, который приходится решать «на лету» и фиксить баги в нём же. Повторюсь, я предлагаю прейти на более чистую технологию, в которой даже не нужен JS.

Напиши браузер на кути, который меняет <input> на виджет со строкой на кути и получишь то же самое

Жаль что ты не обратил внимание, но я говорю но про браузер, а про сам язык разметки. Напиши код «d3o3jdiu3ldkjklwaahdkj<>» и сделай чтобы он визуализировался виджетом. Плохо? А сделай это в виде QML. Думаю мысль понятна.

html староват и для совместимости его оставляли таким, какой он есть, а на момент создания он был адекватен,

Да. И, спешу отметить, что он был «нормальным» для написания простых страниц. Однако потом браузерописатели пошли вперёд и перегнали стандарты, которые потом через ж догоняли браузеры брав всё у самих же браузерописателей.

потому что на html уже есть разница в отрисовке в разных браузерах

Одна одна из мельчайших проблем что решает моя мысль.

И привет совместимости - мы пришли к html заново.

Нет. Дело в том что в Qt все виджеты стандартизированы и имеют сильную документацию, что позволяет избежать непонимания другими тулкитами. Если делать на Qt, то я не думаю что будут такие проблемы. Да и если внезапно произойдёт третья мировая и от кути ничего не останется, а все кутикодеры погибнут, то поблема восприятия не будет столь острой. В конце концов все научены историей IE6.

есть попытка сделать универсальное добро для всех

Не совсем. Сильверлайт и не говорят что приживётся. MS сами говорили что не хотят чтобы люди на него переходили, просто хотят чтобы юзали как и html. Т.е. жить в симбиозе, просто внедрить WPF в веб. Я надеюсь что ты понял что я хотел сказать. FlashFX тоже не айс. Ни у кого нет цели полностью заменить HTML и сделать полнофункциональную замену. А зря. Все всё встраивают в браузеры, думают в слишком узких рамках.

Так что твоя идея о Qt-html ничем не отличается

Как я сказал, отличается. Сильно.

всех использовать одну технологию

Да, это сложно, но web-QML внедрить будет в разы легче чем все эти флеши и мунлайты.

то тогда и html-я хватит.

Нет, ибо он всем надоел и никто просто не увидит реальных причин перейти на Qt-html, а вот на web-QML...

> Браузеры что существуют сейчас(движки, точнее) парсят ужасный код, который приходится решать «на лету» и фиксить баги в нём же. Повторюсь, я предлагаю прейти на более чистую технологию, в которой даже не нужен JS.

Хотели уже на XML перейти, не получилось. Тут такая же ситуация. Так же придется фиксить баги на лету и додумывать за кодера. Вот и получаем второй XHTML.

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

Для решения этих проблем создается HTML5.

потому что на html уже есть разница в отрисовке в разных браузерах

Одна одна из мельчайших проблем что решает моя мысль.

Ошибки будут трактоваться по разному. Разработка HTML5 разрешает эту проблему.

>Хотели уже на XML перейти, не получилось
Эта «хотелка» была в виде пару дискуссий «наверху» о переходе на xhtml, да и то вяло оно было.

Тут такая же ситуация

Ни в коем случае не такая же.

Так же придется фиксить баги на лету

А давай с неба не брать проблемы?

додумывать за кодера

А давай с неба не брать проблемы?

Вот и получаем второй XHTML.

Вот ты и получил XHTML превратив мои мысли в свои. Бред.

Для решения этих проблем создается HTML5.

Для решения этих проблем пришлось доганять выпуская html4. HTML5 это уже другое дело. Браузеры в стандарты не лезли, все юзали флеш.

Ошибки будут трактоваться по разному.

Не будет неверный код работать - не будет ошибок. Не будет ошибок - нечему будет трактоваться.

Разработка HTML5 разрешает эту проблему.

HTML5 и близко к этой проблеме не стоит.

>Хотели уже на XML перейти, не получилось

Эта «хотелка» была в виде пару дискуссий «наверху» о переходе на xhtml, да и то вяло оно было.

Восемь лет работы.

Не будет неверный код работать - не будет ошибок. Не будет ошибок - нечему будет трактоваться.

Вот они так же восемь лет думали. А в реальном мире такого браузера не будет.

HTML5 и близко к этой проблеме не стоит.

Гугли WHATWG.

>Восемь лет работы.
Тогда о таком «внедрении» я не слышах. Можешь дашь ссылку? Как-то оно уж больно тихо было раз небыло особо слышно. Т.е. вообще не слышно.

Вот они так же восемь лет думали

Они 8 лет фигнёй страдали, а я предлагаю не страдать 8 лет фигнёй.

А в реальном мире такого браузера не будет.

А теперь ты гворишь о невозможности такого браузера..

Гугли WHATWG.

И что? У HTML5 нет цели догнать браузеры. Я тебе про это говорю. Ибо браузера давно не кладут ничгео нового в html из отсебятины. Вот заменить flash - да.

В любом случай QTCreator для QML сегфолтится часто, да и вьювер есть только в специальнй сборке. Сыро оно. Будем ждать.
Олсо, в убунту 10,04 альфа 3 кутикриейтор чего-то ждёт при запуске. Т.е. не открывается долго. Потом пишет что не может определить путь до рабочей директории, а в консоль валится ошибка о том что конструктор класса для указания относительного путя вызывается с пустым("") аргументом. Лол.

Альфа убунты такая альфа убунты)

Ну а фигли? Альфа она на то и альфа. Хотя ставил я её только ради qt4.6. Уж больно не хотелось стаивить что-то не родное, да и некоторый софт всё-равно приходится брать из 10,04, а тут он сразу...
И да, Mic пропал из алса-миксера, а в джекд устройства вывода свука имеют индекс не 1 и 2, а 5 и 6 '_'

Flex же, не?

>Тогда о таком «внедрении» я не слышах. Можешь дашь ссылку? Как-то оно уж больно тихо было раз небыло особо слышно. Т.е. вообще не слышно.

Они 8 лет фигнёй страдали, а я предлагаю не страдать 8 лет фигнёй.

http://www.amazon.com/s/?url=search-alias%3Daps&field-keywords=xhtml

http://www.ozon.ru/?context=search&text=xhtml

Неплохо так пострадали. Все бы так страдали фигней.

А теперь ты гворишь о невозможности такого браузера..

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

И получается такая беда: разработчики браузеров создают фичи без стандарта — плохо. Консорциум создает стандарт без разработчиков, в отрыве от реальности (как в нашем случае) — тоже плохо.

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

И вот тут на сцену выходит WHATWG со своим HTML5.

>Неплохо так пострадали. Все бы так страдали фигней.
Ох тыж... Понимаешь, внедрение и разработка - разные вещи.

не волнуют проблемы валидации страниц, им нужна информация

И правильно. Внедрение должно быть правильным, тогда и всё будет ок. Тем более что это внедрение инструмента для получения информации, а не какой-то там линупс(*vagan*). Вот квип почти сразу все стали юзать. Угадаешь почему?

И выберут они те браузеры.

Вот ты фигню сморозил. Сколько раз говорить не будет выбора между браузерами? QML-браузеры будут для одной цели, а http - для другой. Это как квип и браузер. Пользователи выбирали между квипом и браузером? Нет. Они используют и то, и то.

создает стандарт без разработчиков, в отрыве от реальности (как в нашем случае)

Вот ты как, просто пытаешься кидаться какашками даже не посмотрев во что кидаешься. QML уже давно реализован, при этом(ох как ты удивишься, наверно) в РЕАЛЬНОСТИ. В Qt 4.6. И всё ок.

И чтоб все по стандарту.

Ты не читал о чём я пишу, я угадал?

И вот тут на сцену выходит WHATWG со своим HTML5.

- Ребята, а что вы тут делаете?
- Да ничего, уже сделали, теперь ты нам не нужен.

На самом деле™ нужно чтобы CSS научился наконец делать что-то более полезное для внешнего вида страницы. Тот же grid layout. Ибо сейчас костыль на костыле и костылём погоняет.

Да свою задачу CSS выполняет, а большего от него и не требуется. С другой стороны CSS таки пестрит кучей ненужного хлама, который приходится юзать и о существовании которого узнаёшь только при многолетнем опыте.
Вообще сейчас оно фигово: JS+HTML+CSS = пипец. QML позволяет сделать всё это вместе, при этом мне понравилось что можно сделать один интерфейс, а информацию в виде модели, т.е. фактически достаточно одного QML-запроса на весь сайт, а остальное получается в виде json ли чего-нить ещё. Получается не хилая разгрузка сервера и задач пользователя.

Вот бы кто-нибудь взял QML и выдвинул его заместо HTML5, меня просто дико бодрят anchor based layouts

Было бы время и желающие помочь - я бы взялся. Всё-равно сейчас все проекты, что пилю, очень вялы.
Конечно, начать нужно было бы с написания основы на C++, а потом системы плагинов на пайтоне(>:3), ибо проще. Думаю всё более чем реально. Реализовать альфу браузера, продемонстрировать работу с джанго, пайлонс и пхп. Сделать пару смелых заявлений и... Они наши >:3.

http://code.google.com/p/qtqmlbrowserplugin/

Ну смотри, почти все нормальные cms работают через qml, поэтому достаточно сделать некий более менее универсальный клиент, который бы принимал данные от сервера в виде json объектов и всё, дело в шляпе. Я вот к примеру сделал небольшой клиентик к быдловконтакту http://gitorious.org/qutim/labs Я бы может и присоединился... Но сейчас мы заняты тем, что на Кутим qml натягиваем. Получается с переменным успехом, но кое какие вещи уже реально работают и радуют.

>Да свою задачу CSS выполняет, а большего от него и не требуется.

Как раз таки требуется, ибо HTML не предоставляет всего необходимого для создания интерфейса. Если с него это заботу снять и оставить только более другие вещи (шрифты, рамки и т.д.), то да.

т.е. фактически достаточно одного QML-запроса на весь сайт, а остальное получается в виде json ли чего-нить ещё

Нечто подобное возможно с XSLT. Передавать только данные в XML потом уже. Но XML осиливают не все. Проблему отображения само по себе это, конечно, не решает (ибо CSS не умеет).

А так, я думаю, это всё вряд ли возможно. Браузерописатели XHTML2 закопали просто потому, что не во всём в синтаксисе совместим с (X)HTML'ами предыдущими, а ты хочешь QML'ом вообще всё заменить.

Хотя с точки зрения того, как бы это могло бы быть, было бы интересно посмотреть. // В QML пока тыкать палочкой не доводилось.

Нет, это не то. Я уже 3 таких «проекта» видел. У них другие цели. Они просто хотят встроить QML-приложения в HTTP, а это - ужас. В конце концов может получиться тот-же флеш.
Моя же мысль - полностью заменить HTTP-часть QML-кодом. Полностью избавиться от HTTP и получить возможность удобного создания страниц именно на QML.

>все нормальные cms работают через qml
Что? Я как-то не понял. Может ты не про QtML говоришь?

достаточно сделать некий более менее универсальный клиент

Да, при этом я думаю что лучшим вариантом было бы сделать такой клиент с архитектурой хромиума, который может открывать во вкладках веб-кит процессор или qml-процессор. Получилось бы как-раз для всего: и для HTML, и для QML.

который бы принимал данные от сервера в виде json объектов

А так оно и должно быть в QML-моделях и есть в AJAX.

сделал небольшой клиентик к быдловконтакту

А, значит я читал твою статью на хабре. Интересно, конечно. Было бы хорошо иметь в «команде» человека, который уже много поработал с QML.

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

Да, ибо пока сыровато но... Реализация такого «браузера» очень была бы кстати.

>HTML не предоставляет всего необходимого для создания интерфейса.
Увы. Да и не его это задача. Если QML является языком общего описания интерфейса, а точнее его объектов с их свойствами.
HTML же используется как прямое(raw, но не direct) описание интерфейса в конкретном(текущем) состоянии. Т.е. задачу HTML выполняет. Что же такое CSS? Это язык для описания стилей, не более. И здесь он выполняет свою задачу. И проблемы HTML ни коем образом не волнуют CSS.

Как раз таки требуется

И что, по твоему мнению, от CSS требуется ещё?

Нечто подобное возможно с XSLT

Да, возможно. Но QML интереснее, фичастее и быстрее.

А так, я думаю, это всё вряд ли возможно

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

XHTML2 закопали просто потому

А почему? Да потому что профита никакого не получается. Киллер-фич нет. По сути этот просто небольшая стандартизация, которая имеет большой минус - убивает обратную совместимость. Торт не стоит свеч, иначе говоря.

а ты хочешь QML'ом вообще всё заменить

Не совсем и не просто заменить. Киллерфич в QML достаточно, да и скорость и удобство разработки возрастёт во много раз. А из минусов... Да тот-же один минус XHTML2 - 0-вая обратная совместимость. Но если в браузере сделать поддержку вебкита, то вполне можно даже отказаться от обычных бразуеров.

было бы интересно посмотреть

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

>Ох тыж... Понимаешь, внедрение и разработка - разные вещи.

Ты реально пропустил всю эту шумиху с новомодными XHTML и CSS? Это был вообще-то действующий стандарт. Всем объявили, мы переходим на XML. Кто не снами, в один прекасный день ваши не XML сайты просто перестанут работать. И всё, куда деваться, пошел процесс. И все эти книги, один из показателей этого процесса.

Вот квип почти сразу все стали юзать. Угадаешь почему?

Потому что он был юзабельнее других клиентов, не?

QML-браузеры будут для одной цели, а http - для другой. Это как квип и браузер. Пользователи выбирали между квипом и браузером? Нет. Они используют и то, и то.

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

А тот самый знаменитый Вася, сделает свой QML-браузер VANGA EDITION с блекдж^W «фиксингом багов на лету». И на Васин юзабельный «кип» перейдут и пользователи, и быдлокодеры.

Ты не читал о чём я пишу, я угадал?

Я тебе не говорю, что XML плохой, что QML плохой, что стандарт плохой. Я тебе говорю — Вася плохой, быдлокодеры плохие. И их больше, чем нас.

- Да ничего, уже сделали, теперь ты нам не нужен.

Еще делают.

>пропустил всю эту шумиху с новомодными XHTML и CSS
Нет, просто я не совсем понял про что ты говоришь :)
Таки 8 лет никто не внедрял. Хорошо умеют внедрять банки отменяя старый формат дампов банк-клиентов и внедряя другой, чуть боле новый. А XHTML...

Потому что он был юзабельнее других клиентов, не?

Да, это основная из причин. Почему бы данный пример не применить и на данный случай? Фактически, если популяризировать QML, то людям будет удобнее использовать QML-интерфейс для вконтактов/фейсбуков etc etc. Вот что мы сейчас наблюдаем? «У меня вконтакт лагает», «долго грузится», «опять кто-то поместил тег в статус и теперь косяки в вёрстке». Да хоть такие банальные проблемы. QML же лишён не просто таких проблем(ибо фактически самым лучшим дизайном QML-приложения будет 1 интерфейс + модели, что заметно сократит трафик, время отклика, отклик интерфейса), он позволяет решить и проблему нагрузки на браузеры(флеш, DOM, ajax, JS, реалтайм-фиксинг html).

Быдлокодеры с ошибками пойдут лесом.

А это плохо? Для хорошего сайта нужен хороший код, а быдлокодеры не нужны.

VANGA EDITION с блекдж^W «фиксингом багов на лету»

А из-за реал-тайм фиксинга получится что? Представь ФФ - это как-раз то что получится. А представь хромиум без флеша - это то что будет у меня, даже быстрее. Сам по себе чекинг на ошибки и множественные проверки занимают, мягко говоря, много процессорного времени. Оно просто ужасно. Однако! Если следовать MVC-модели при построении QML-приложений, чекинг и фиксинг будет необходим только при первом запросе, т.е. открытии страницы => нагрузка не так велика.

Я тебе говорю — Вася плохой, быдлокодеры плохие. И их больше, чем нас.

Ну вот пусть Вася и делает свой препорцессор корявого QML. Пусть делает что хочет. Поживём - увидим. В конце концов, есл ипредставить что вот он такой крутой и создаст действительно крутой, быстрый QML-браузер, который быстрее «моего», то пусть живёт. В конце концов, как я написал выше, оно не подействует сильно на общую производительность.

Еще делают.

Сам QML уже сделали и продолжают делать. Если его не развивают, значит он мёртв :)

Что? Я как-то не понял. Может ты не про QtML говоришь?

Да я опечатался, имел в виду json конечно

А, ок. Ну я бы не сказал что они «работают». Ни одна нормальная CMS не работает только через JSON(т.е. я имею ввиду AJAX). Всё-таки пока я не вижу ни одного сайта(а я молу про CMS), который полностью перешёл бы на AJAX + 1-2 страницы.

durov.ru Но вообще пока в QML еще даже таблиц и деревьев нету.

>durov.ru
Супер. Только стоит оно, по времени разработки, не хило. Да и код пугает. А как оно в других браузерах будет работать... У меня хромиум и всё ок, а вот в мидори с 20 вкладками как-то не очень.

еще даже таблиц и деревьев нету

А разве в QML нельзя юзать любые qt-виджеты? Вроде как можно, а в кутях для этого всё есть.

Можно, но не желательно. Да и если ты для веба это планируешь, то такой вариант не годится

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

>Это язык для описания стилей, не более. И здесь он выполняет свою задачу.

Оформление и компоновка уже давно дело этих же стилей, потому они тот же grid layout и пытаются изобрести. Но пока, помнится, никто это реализовывать ещё не начал, только через скрипты.

Но QML интереснее, фичастее и быстрее.

Про бытро не знаю, про то, что фичастее, то, конечно, ибо сам XSLT то никаких средств для создания оформления не предостовляет. QML есть только в Qt 4.6.x, помнится? До тестинга это добро не доползло ещё…

>компоновка
М? Ты про это, ну да, есть куда развиваться.

Про бытро не знаю

Процессинг QML явно быстрее процессинга HTML. Да думаю что даже быстрее процессинга XHTML, если бы он был «чистым».

До тестинга это добро не доползло ещё…

Дебиан? Там много чего ещё до тестинга не доросло, но это не значит что это нельзя юзать. Да даже если бы 4.6 был на столько сырым, то это не значит что нужно ждать его стабильности для реализации такого проекта.

Да, и это правильно, мы тут немало багов в этом QML нашли))) Зато есть надежда, что к релизу они будут пофикшены. Хочется, чтобы к моменту релиза технологии уже был отличный рабочий образец на ней, к этому и стремимся :)

Оформление и компоновка уже давно дело этих же стилей, потому они тот же grid layout и пытаются изобрести.

По сравнению с anchor based layouts он какой-то уж совсем детский. Одним gridом много не добъешься. Вот только, к сожалению, сейчас уже нашими маленькими усилиями едва ли получится раскачать такую махину, как веб. Вот если бы например с фейсбуком договорится, чтобы они QML клиента сделали, то тогда это будет определённо победой. QML, кстати, уже сейчас позволяет из интернета подтягивать дополнительные qml модули и скрипты.

Угу, вот такой-же логикой и хочу следовать если делать QML-тулкит и браузер.
Вообще оно сейчас не так глючно как некоторый софт, который пропускают в тестинг в дебиан.

>но это не значит что это нельзя юзать

Не, это я о том, что не могу попробовать и проверить :)

Сделать просто «клиент» вроде отдельной фичи - профита мало. Да и в сторону веб оно не пойдёт. Прикладнуха, опять. А так оно пойдёт дальше в прикладное, пока не потеряет шансы попасть в веб из-за того что разработчики не будут сильно заботиться о аспектах, важных для веб-разработок.
Следовательно, нужно договориться о разработки QML-фронтэнда для фейсбука, но как работать с этим если нет даже браузера?

>anchor based layouts

Есть какой-нибудь линк? Или я просто не пойму что имеется в виду.

XML

повбывал бы