XULRUNNER подходит как замена для других настольных приложений С++, таких как QT?

XulRunner/Gecko, по-видимому, действительно интересен для разработки приложений с интенсивным графическим интерфейсом (с использованием широко используемых технологий, таких как HTML/CSS/SVG/XUL/Javascript). Но подкладка С++ APIS (XPCOM, NECKO,...) выглядит настолько старой и сложной. Кроме того, общий недостаток инструментов документации/разработки действительно пугает.

С другой стороны, QT имеет неплохую платформу и хорошо документирован и поддерживается. Часть пользовательского интерфейса действительно "традиционная".

Каковы ваши впечатления от XULRUNNER, особенно по сравнению с другими платформами настольных приложений С++, такими как QT/GTK/MFC...? Чего не хватает? Что удивительно?

Боковой вопрос: если бы я захотел перенести существующее приложение MFC в платформу для настольных приложений на платформе С++, было бы разумно использовать XULRUNNER вместо QT или GTK?

Ответ 1

На самом деле не так много приложений, построенных с использованием XulRunner, насколько мне известно. И я должен знать, поскольку я был Tech Lead для одного из них, и мы попытались нанять опытных людей. Оглядываясь назад, это меня не удивляет. Наше решение использовать XulRunner было сделано не разработчиком, по моему совету. Многие вещи занимали в два раза больше времени, которое они использовали бы в wxWidgets, которые мы использовали раньше. Теперь я также использовал Qt в других проектах, и я должен сказать это даже лучше, чем wxWidgets. Поэтому я могу с уверенностью утверждать, что Qt будет более чем в два раза эффективнее XulRunner, и, кроме того, вам будет намного легче найти опытных разработчиков.

Конечно, Javascript в XulRunner хорош. Но Qt также поставляется с QtScript, который обертывает JavaScriptCore. И когда дело доходит до создания действительно богатого пользовательского интерфейса - то есть больше, чем просто стопки изображений - тогда HTML + SVG + CSS + JS просто не сокращает его. Они были разработаны, чтобы упростить простые вещи, а не создавать сложные вещи. Просто посмотрите на новейшую функцию, видео. Решение HTML5: тег, и пусть некоторые С++-коды за кулисами делают настоящую работу. Несмотря на то, что видео - это просто большой стек изображений, показанных по одному за раз.

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

На удивительной стороне механизм плагина работает очень хорошо.

Теперь это применимо, если вы начинаете с нуля. Если у вас уже есть много кода MFC/С++, придерживайтесь С++ и отбрасывайте только часть MFC. Это означает, что Qt или, возможно, wxWidgets являются очевидными победителями.

Ответ 2

Честно говоря, я просто не согласен с тем, что там не так много приложений XULRunner... есть нагрузки, это всего лишь некоторые из тех, о которых знает Mozilla:

https://developer.mozilla.org/en/xulrunner_hall_of_fame

developer.mozilla.org/en/List_of_Mozilla-Based_Applications

Это, конечно, исключает самих Firefox и Thunderbird!

Наши собственные перечислены там www.redbacksystems.com/liaison/

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

Почему бы вам не захотеть писать в QT или GTK, когда вы можете писать в стандартах, совместимых со стандартами JavaScript/ECMA, включая E4X, с исключительной поддержкой CSS и XML - включая XBL (хотя и 1.0), RDF, XML Templating, удаленное обновление, поддержка плагинов и расширений и т.д. и т.д. и т.д. и даже не запускать меня по геолокации или встроенной поддержке SQL.

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

Для меня инструментарий Mozilla является платформой выбора bar none.

Кстати, как я понимаю, у Joost были особые проблемы, поскольку они писали/реализовывали свои собственные видеорекламы и пытались также использовать контент DRM.

Ответ 3

Я не думаю, что вы действительно хотите написать XUL-код на С++. Цель API XPCOM и т.д. Заключается в том, что вы можете взаимодействовать с существующими библиотеками C или если вам нужно писать специфичные для платформы вещи, которые требуют вызова API за пределами механизма javascript.

Если вы хотите написать кросс-платформенное графическое приложение в javascript, хотя это может быть то, что вы ищете.

Ответ 4

Я не был в этой команде, но настольное приложение joost использовало XULRUNNER для пользовательского интерфейса. Хотя это вариант, я лично не тронул бы его палкой для кросс-платформенных графических интерфейсов. На самом деле мой опыт показывает, что наличие одного кросс-платформенного приложения всегда будет подпадать.

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

Ответ 5

Кто-нибудь попробовал это?

XUL Viewer http://code.google.com/p/xulwin/

Это довольно удивительный проект. чистый код, несколько зависимостей (только poco-basic и boost)

Woot!