Помимо всего прочего — куте не только гуевая либа. Не стоит этого забывать.

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

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

C>>>HTMLayout. Лучше нет ничего.
A>>на самом деле есть. Qt.
C>Нет, я пробовал.

A>>Объясню почему он мне нравиться больше HTML layout.
A>>Плюсы:
A>>1) Для описания UI можно использовать стандартную связку HTML+JavaScript+CSS (+jQuery), нестандартные расширения (css 3) будут работать минимум в 5 браузерах (Chrome, Safari, Maxthon, Konqueror, Arora). UI можно тестировать с помощью любого из перечисленных браузеров.
C>В HTMLayout лучше, там css реально работает. И есть удобнейшие flex units.

A>>2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
C>Ну да, тут плюс.
Еще плюс — у webkit-а открыты исходники. Мне это реально помогало отлаживаться, выбирать оптимальный сценарий в скриптах по генерации UI (отображение произвольно большого списка) и решить нетривиальный баг с отрисовкой плагинов на "старой" версии Qt (4.5.2).

A>>3) Кроссплатформенность — Mac OS X, Linux, Windows.
C>В HTMLayout будет к концу года. И он уже есть на WinCE, на который пока QT портировать проблематично.
А на Mac OS X будет?

A>>4) Хорошая интеграция с С++:
C>Есть.
Такая же хорошая как в Qt?
То есть описал метод-слот и забыл?
Или нужен еще дополнительный код с биндингом?

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

C>...

И еще — можно ли использовать jQuery c HTMLayout?
Сам я, правда, jQuery пока не использую, ибо не целесообразно пока, но давно присматриваюсь.

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

C>>...
A>И еще — можно ли использовать jQuery c HTMLayout?
A>Сам я, правда, jQuery пока не использую, ибо не целесообразно пока, но давно присматриваюсь.
Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.

В Java-обёртке мы сделали JQuery-подобный API:

        $(".navigate [action]", element).listen(new BehaviorEventListener()
        {
            @Override
            public boolean onBehaviorEvent(final BehaviorEventEvent event, final HElement button)
            {
            ...
            }
        }

Для С++ никто не мешает сделать такое же, если не хватает стандартных декораторов.

Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.

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

A>>>2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
C>>Ну да, тут плюс.
A>Еще плюс — у webkit-а открыты исходники. Мне это реально помогало отлаживаться, выбирать оптимальный сценарий в скриптах по генерации UI (отображение произвольно большого списка) и решить нетривиальный баг с отрисовкой плагинов на "старой" версии Qt (4.5.2).
Стоп-стоп-стоп. Мы говорим о WebKit'е или QT? На самом WebKit'е писать не особо приятно (я пробовал), не хватает многих необходимых вещей. Скажем, резиновый UI без таблиц никак не сделать, свои behavior'ы тоже нормально не прикручиваются. Тут WebKit сливает HTMLayout'у по полной.

Если мы говорим о самой QT как interface framework, то ситуация другая — там нет нормального CSS, скажем.

Ну и исходники HTMLayout можно получить при желании.

A>>>3) Кроссплатформенность — Mac OS X, Linux, Windows.
C>>В HTMLayout будет к концу года. И он уже есть на WinCE, на который пока QT портировать проблематично.
A>А на Mac OS X будет?
Как только я куплю Мак.

A>>>4) Хорошая интеграция с С++:
C>>Есть.
A>Такая же хорошая как в Qt?
Она просто другая.

A>То есть описал метод-слот и забыл?
A>Или нужен еще дополнительный код с биндингом?
Я когда писал на С++ — делал байндинги с помощью boost::bind+boost::function. Оно получается более правильно, чем система слотов. Ну и в HTMLayout оно немного меньше нужно, особенно если взять Sciter.

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

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

A>>>>2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
C>>>Ну да, тут плюс.
A>>Еще плюс — у webkit-а открыты исходники. Мне это реально помогало отлаживаться, выбирать оптимальный сценарий в скриптах по генерации UI (отображение произвольно большого списка) и решить нетривиальный баг с отрисовкой плагинов на "старой" версии Qt (4.5.2).
C>Стоп-стоп-стоп. Мы говорим о WebKit'е или QT? На самом WebKit'е писать не особо приятно (я пробовал), не хватает многих необходимых вещей. Скажем, резиновый UI без таблиц никак не сделать, свои behavior'ы тоже нормально не прикручиваются. Тут WebKit сливает HTMLayout'у по полной.

Я говорю только о QtWebKit.
По поводу "сливает" — это голословно.
Допустим behaviors в WebKit нет. Потому что они не стандартизированы w3c.
И не факт, что жить без них нельзя никак.
Примеры интерфейсов о которых я говорю —
http://jqueryui.com/demos/tabs/
http://jqueryui.com/demos/datepicker/
и т.п.

На WebKit+JS доступен, например Wolfenstein 3D — http://www.nihilogic.dk/labs/wolf/
Не уверен что будет работать в мозилле, но в хроме и сафари работает довольно шустро.


C>Если мы говорим о самой QT как interface framework, то ситуация другая — там нет нормального CSS, скажем.
согласен, qss пока бедноват для rich-interface приложения.

C>Ну и исходники HTMLayout можно получить при желании.

Хорошо. Вот к примеру мне было бы интересно взглянуть на исходники HTMLayot (на самом деле), просто для образовательных целей. Как мне получить исходники?

A>>>>3) Кроссплатформенность — Mac OS X, Linux, Windows.
C>>>В HTMLayout будет к концу года. И он уже есть на WinCE, на который пока QT портировать проблематично.
A>>А на Mac OS X будет?
C>Как только я куплю Мак.

A>>>>4) Хорошая интеграция с С++:
C>>>Есть.
A>>Такая же хорошая как в Qt?
C>Она просто другая.

Насколько другая?
Пример разработки с QtWebKit:
1) описываем тестовый источник данных (на js) и html, тестируем-отлаживаем все в браузере с удобнейшим FireBug, редактируем в любимом редакторе.
2) перенос на С++ заключается только в описании источника данных с такими же именами слотов.

пример:
моделируемый источник данных и его заполнение тестовыми данными описан в test_data.js:

function TestData(foo, bar, baz) {
...
}
...
TestData.prototype.getFoo = function() {
    return this.foo;
}

TestData.prototype.getBar = function() {
    return this.bar;
}

TestData.prototype.getBaz = function() {
    return this.baz;
}
...
function getTestData() { return new TestData(...); }

нужно написать его аналог на С++ и заменить исходный тестовый на новый, нативный:
достаточно описать test_data.cpp

class TestData : public QObject
{
...
public slots:
 QString getFoo() {..}
 QString getBar() {..}
 QString getBaz() {..}
};

и все!

Замена на новый источник данных может быть сделана тривиально в коде загрузки источника данных:

var data;
try {
data  = cppData;
}
catch (err) {
// используем тестовый источник данных, если не привязан С++ объект cppData
data = getTestData();
}

соответственно привязка cppDataSource делается тривиально из кода:

frame->addToJavaScriptWindowObject("cppData", new TestData(...));

A>>То есть описал метод-слот и забыл?
A>>Или нужен еще дополнительный код с биндингом?
C>Я когда писал на С++ — делал байндинги с помощью boost::bind+boost::function. Оно получается более правильно, чем система слотов. Ну и в HTMLayout оно немного меньше нужно, особенно если взять Sciter.

Насчет правильности — в принципе не согласен. Это слишком субъективное понятие

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

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

C>>>...
A>>И еще — можно ли использовать jQuery c HTMLayout?
A>>Сам я, правда, jQuery пока не использую, ибо не целесообразно пока, но давно присматриваюсь.
C>Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.
C>Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.

я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
В вебкит эта возможность доступна out-of-the-box.

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

C>>Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.
C>>Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.
A>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>В вебкит эта возможность доступна out-of-the-box.
Большинство анимаций в HTMLayout вообще декларативно задаются в CSS. Поведение контролов делется с помощью behavior'ов. Т.е. как таковой надобности в JQuery-контролах нет.

При желании можно сделать, конечно.

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

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

C>>>Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.
C>>>Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.
A>>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>>В вебкит эта возможность доступна out-of-the-box.
C>Большинство анимаций в HTMLayout вообще декларативно задаются в CSS. Поведение контролов делется с помощью behavior'ов. Т.е. как таковой надобности в JQuery-контролах нет.

Это к вопросу о повторной используемости. jQuery предлагает много поддерживаемых и нетривиальных решений для достаточно сложных аспектов разработки UI — themes, item views, drag'n'drop, tab widgets, и т.п.
Не сомневаюсь, что подобное можно повторить на HTMLayout, однако, по всей видимости, не настолько же просто как с jQuery — путем простого подключения соответствующего модуля и создания объекта (взять любой из приведенных выше примеров с jQuery UI).

C>При желании можно сделать, конечно.

то есть HTMLayout + Sciter полностью поддерживают jQuery out-of-the-box? Или все таки надо что-то допиливать?

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

C>>Стоп-стоп-стоп. Мы говорим о WebKit'е или QT? На самом WebKit'е писать не особо приятно (я пробовал), не хватает многих необходимых вещей. Скажем, резиновый UI без таблиц никак не сделать, свои behavior'ы тоже нормально не прикручиваются. Тут WebKit сливает HTMLayout'у по полной.
A>Я говорю только о QtWebKit.
A>По поводу "сливает" — это голословно.
Ничуть. Нормальный резиновый UI на чистом CSS не делается.

A>Допустим behaviors в WebKit нет. Потому что они не стандартизированы w3c.
Behavior в HTMLayout'е — это просто аналог контрола. Причём все контролы самого HTMLayout'а реализованы как обычные behavior'ы.

A>И не факт, что жить без них нельзя никак.
Нельзя.

A>Примеры интерфейсов о которых я говорю -
A>http://jqueryui.com/demos/tabs/
A>http://jqueryui.com/demos/datepicker/
A>и т.п.
Аналогичное всё делается, но другими механизмами.

Для табов в HTML будет вот это:

<div class="tabs">
    <div class="strip"> <!-- заголовки табов -->
        <div panel="tab1" selected="true" accesskey="t"><u>T</u>ab One</div>
        <div panel="tab2" accesskey="w">Tab t<u>w</u>o</div>
    </div>
    <div id="tab1"> Первый таб </div>
    <div id="tab2"> Второй таб </div>
</div>

И с помощью CSS подвязывается нужный behavior:

.tabs {
    behavior: tabs;
}

Код behavior'а сюда cut&paste'ить не буду.

A>На WebKit+JS доступен, например Wolfenstein 3D — http://www.nihilogic.dk/labs/wolf/
A>Не уверен что будет работать в мозилле, но в хроме и сафари работает довольно шустро.
Причём тут это — вообще непонятно. В HTMLayout'е берёшь графическую поверхность нужного элемента, и хоть FarCry на ней рисуй. С помощью нормального нативного кода, а не на JS.

C>>Ну и исходники HTMLayout можно получить при желании.
A>Хорошо. Вот к примеру мне было бы интересно взглянуть на исходники HTMLayot (на самом деле), просто для образовательных целей. Как мне получить исходники?
Пишешь csmile'у и объясняешь зачем они тебе нужны

A>>>Такая же хорошая как в Qt?
C>>Она просто другая.
A>Насколько другая?
Сильно.

A>Пример разработки с QtWebKit:
A>1) описываем тестовый источник данных (на js) и html, тестируем-отлаживаем все в браузере с удобнейшим FireBug, редактируем в любимом редакторе.
A>2) перенос на С++ заключается только в описании источника данных с такими же именами слотов.
На HTMLayout можно так делать, но не нужно. Проблема в том, что тебе придётся большую часть логики UI делать на JS, что лично мне неудобно. Использование (по сути) RPC для связи с С++ тоже мне не очень приятно.

С HTMLayout мне больше нравится более другая схема — HTMLayout занимается отображением и всякой там анимацией, а код на С++ — всем остальным. Т.е. можно прямо вешать обработчики событий на элементы управления и напрямую привязывать контролы к источникам данных.

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

C>>Большинство анимаций в HTMLayout вообще декларативно задаются в CSS. Поведение контролов делется с помощью behavior'ов. Т.е. как таковой надобности в JQuery-контролах нет.
A>Это к вопросу о повторной используемости.
А кто ей мешает? Behavior'ы замечательно переиспользуются.

A>jQuery предлагает много поддерживаемых и нетривиальных решений для достаточно сложных аспектов разработки UI — themes, item views, drag'n'drop, tab widgets, и т.п.
Ряд этого не очень нужен, так как темы лучше и удобнее делать своими средствами HTMLayout'а. Табы — обычный behavior, идущий в стандартном SDK как пример.

D&D в HTMLayout'е сделан удобнее, чем в обычном HTML. В Sciter'е с ним вообще улётные демы есть.

A>Не сомневаюсь, что подобное можно повторить на HTMLayout, однако, по всей видимости, не настолько же просто как с jQuery — путем простого подключения соответствующего модуля и создания объекта (взять любой из приведенных выше примеров с jQuery UI).
Подключение табов, к примеру, делается включением в проект файла behavior_tabs.cpp и его CSS-ки. Всё, ничего больше делать не надо.

C>>При желании можно сделать, конечно.
A>то есть HTMLayout + Sciter полностью поддерживают jQuery out-of-the-box? Или все таки надо что-то допиливать?
Sciter — это не JS. Там свой язык со своими фичами, частично болеее удобными, чем есть в JS.

Я его не использую Хватает HTMLayout + Java.

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

C>...

OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).

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

C>>...
A>OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
A>1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.

A>2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).
Так не получится, так как бинарная версия — бесплатна для коммерческого использования.

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

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

C>>>...
A>>OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
A>>1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
C>Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.

И что, вы сделаете либу для всех популярных архитектур и дистрибутивов? ppc, mips, x86-64, arm? Yellow Dog, Ubuntu, Red Hat, MCBC?

A>>2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).
C>Так не получится, так как бинарная версия — бесплатна для коммерческого использования.

Получится. Если автор захочет (и очень жаль, что он не хочет).

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

A>>>OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
A>>>1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
C>>Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.
A>И что, вы сделаете либу для всех популярных архитектур и дистрибутивов? ppc, mips, x86-64, arm? Yellow Dog, Ubuntu, Red Hat, MCBC?
А какие проблемы? На ARM и MIPS оно уже работает (под WinCE). Кросс-компиляцию на PPC я точно сделаю, остальные архитктуры особой проблемы тем более не составят.

A>>>2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).
C>>Так не получится, так как бинарная версия — бесплатна для коммерческого использования.
A>Получится. Если автор захочет (и очень жаль, что он не хочет).
У него на это вполне нормальные причины.

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

A>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>В вебкит эта возможность доступна out-of-the-box.
Кстати, посмотрел внимательнее на JQuery tabs.

Ну и маздай.

Клавиатурной навигации нет, горячих клавиш нет, табы не фокусабельные.

Стоит ли говорить, что в HTMLayout оно всё есть?

Здравствуйте, pepsicoca, Вы писали:
P>Добрый день.

P>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

P>Спасибо.

попробуй http://ultimatepp.org

сравнение с Qt http://ultimatepp.org/www$uppweb$vsqt$en-us.html
сравнение с wxWidgets http://ultimatepp.org/www$uppweb$vswx$en-us.html
сравнение с Swing http://ultimatepp.org/www$uppweb$vsswing$en-us.html

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

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

A>>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>>В вебкит эта возможность доступна out-of-the-box.
C>Кстати, посмотрел внимательнее на JQuery tabs.

C>Ну и маздай.

C>Клавиатурной навигации нет, горячих клавиш нет, табы не фокусабельные.

C>Стоит ли говорить, что в HTMLayout оно всё есть?

В контексте моего сообщения это скорее proof-of-concept, или то, что можно сделать. Я не разбирал подробно пример — возможно, что можно очень легко прикрутить клавиатурную навигацию.
В своей работе jQuery я пока не использую, так что квалифицированно ответить по тонкостям использования jQuery увы не смогу.

Плюс к тому jQuery решения портируемы на практически любой браузер (читай портируемое веб-решение). Чего нельзя сказать о HTMLayout.

Наконец подход HTMLayout-а мне в целом не нравится — например описание поведений в С++ коде.
Я предпочитаю видеть описание всего UI отдельно от C++ кода, в котором (опять же с моей точке зрения) лучше описывать только источники данных и основные элементы биндинга.
Подход, в котором динамика(поведение) описывается в js файлах при котором мы получаем максимально реюзабельный код мне видится более "правильным" нежели принятый в HTMLayout, синтаксические расширения которого непортируемы на другой браузер и не могут быть переиспользованы при отходе от HTMLayout-а в сторону другого HTML-движка (Gecko, Presto, WebKit etc.).

Хочу повторить, что вопросы "правильности" здесь по большему счету субъективны, это просто мое мнение

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

C>>Стоит ли говорить, что в HTMLayout оно всё есть?
A>В контексте моего сообщения это скорее proof-of-concept, или то, что можно сделать. Я не разбирал подробно пример — возможно, что можно очень легко прикрутить клавиатурную навигацию.
Можно, но не особо легко. С taborder'ом и фокусом в HTML всё плохо.

В этом и проблема HTML — не задумывался он для приложений.

A>В своей работе jQuery я пока не использую, так что квалифицированно ответить по тонкостям использования jQuery увы не смогу.
A>Плюс к тому jQuery решения портируемы на практически любой браузер (читай портируемое веб-решение). Чего нельзя сказать о HTMLayout.
А нафиг оно для десктопного приложения? Если мечта о том, чтобы можно было десктопное приложение засунуть сразу в браузер — то можно забыть, слишком разные подходы.

A>Наконец подход HTMLayout-а мне в целом не нравится — например описание поведений в С++ коде.
A>Я предпочитаю видеть описание всего UI отдельно от C++ кода, в котором (опять же с моей точке зрения) лучше описывать только источники данных и основные элементы биндинга.
Неудобно для сложных интерфейсов.

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

C>...
C>У него на это вполне нормальные причины.

Кстати, а почему? Если не секрет.
По моему разумению возможны такие варианты:

1) Автор хочет заработать на библиотеке. В этом случае исходники не раскрываются, бинарь продается или предоставляется в бесплатное пользование, сорцы выдаются за отдельную плату по особой лицензии.
2) Автор хочет предоставить библиотеку в бесплатное пользование населению (а я так понимаю это наш случай )
В этом случае почему бы не выложить исходники в общий доступ (code.google.com) и допустить вариант дальнейшего развития библиотеки по лицензии GPL, а тем кто хочет использовать ее в коммерческих целях предлагать коммерческую лицензию.
Либо (совсем хорошо) предоставить библиотеку в LGPL(BSD/Artistic).
IMHO HTMLayout от такого решения только выиграет...