Доброго дня!

По просьбе пользователей добавляю поддержку Qt4 в текущую версию MxxRu 1.4.7. Пока получилось вот что (на примере демки books из Qt 4.4.3 (каталог $QTDIR/demos/books)):

require 'mxx_ru/cpp'
require 'mxx_ru/cpp/qt4'

MxxRu::Cpp::exe_target {

  target 'books'

  cpp_sources Dir[ '*.cpp' ]

  qt = generator MxxRu::Cpp::Qt4.new( self, %w[QT_GUI_LIB QT_CORE_LIB QT_SQL_LIB] )

  qt.h2moc 'bookwindow.h'
  qt.ui 'bookwindow.ui'

  qt.qrc 'books.qrc'

  lib 'qtmain'
  lib 'QtSql4'
  lib 'QtGui4'
  lib 'QtCore4'
}

пока не бог весть что, поэтому хочется улучшить. Но, поскольку сам я Qt4 пока нигде не использовал, то хочется обратиться за помощью к более сведующим людям.

Итак, вот какие мысли.

1. В Qt4 присутствуют несколько библиотек (QtCore, QtGui, QtSql, QtNetwork и т.д.). Для того, чтобы их использовать в своем проекте, необходимо проделать два действия:
— определить соответствующий define (например, QT_CORE_LIB для QtCore);
— подключить к проекту соответствующую библиотеку.
Я думаю, что пользователям MxxRu было бы удобнее поступать так:

MxxRu::Cpp::exe_target {
  ...
  qt = generator MxxRu::Cpp::Qt4.new( self )
  qt.core.gui.sql.network
  ...

За строчкой 'qt.core.gui.sql.network' будут скрываться define QT_CORE_LIB, QT_GUI_LIB, QT_SQL_LIB, QT_NETWORK_LIB и библиотеки QtCore4, QtGui4, QtSql4, QtNetwork4.

Удобен ли будет такой способ задания библиотек Qt4 или есть какие-то более удачные альтернативы?

2. Сейчас в MxxRu 1.4.7 при задании qrc-файла из него строится cpp-файл, но в список зависимостей к этому файлу ничего не добавляется кроме самого qrc-файла. Т.е. если в qrc-файле заданы картинки a.png и b.jpg, то make-правило для cpp-файла будет иметь вид:

qrc_X.cpp: X.qrc
  rcc -name X -o qrc_X.cpp X.qrc

а хотелось бы, чтобы оно имело вид:

qrc_X.cpp: X.qrc a.png b.png
  rcc -name X -o qrc_X.cpp X.qrc

Для этого нужно распарсить qrc-файл. Это XML, но где можно найти его схему, чтобы понять, что в нем может быть, а чего не может?

3. При запуске компилятора ресурсов Qt ему можно передавать разные параметры. Вопрос в том, какой уровень контроля за этими параметрами нужно передавать пользователю MxxRu? И если передавать, то каким образом.

Вот например, параметр -name сейчас формируется из имени qrc-файла. Т.е. если задано имя books.qrc, и параметр -name будет иметь значение books. Бывают ли случаи, когда имя qrc-файла должно отличаться от имени в параметре -name?

Пользуется ли кто-нибудь параметром -root? Для чего этот параметр нужен?

Пользуется ли кто-нибудь параметром -binary? Для чего этот параметр нужен и что получается при его использовании?


Заранее спасибо за помощь.

PS. Текущая версия MxxRu 1.4.7 находится в Subversion-репозитории: http://mxx-ru.rubyforge.org/svn/branches/1.4/
Если кто-то хочет ее пощупать, но не может взять ее из репозиторя, я могу выслать готовый gem-файл.

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

E>Для этого нужно распарсить qrc-файл. Это XML, но где можно найти его схему, чтобы понять, что в нем может быть, а чего не может?

Здесь кое-какая информация имеется: http://doc.trolltech.com/4.4/resources.html

E>Пользуется ли кто-нибудь параметром -root? Для чего этот параметр нужен?

-root, насколько я понял, нужен для того, чтобы ресурс в коде был доступен по имени полного пути к нему.
По умолчанию в приложении доступ к той же картинке будет по следующему имени: :/images/cut.png, т.е.
по относительному пути, ну а если кому-то хочется по полному пути обращаться к картинке, то вот тут параметр
-root и поможет.

E>Пользуется ли кто-нибудь параметром -binary? Для чего этот параметр нужен и что получается при его использовании?

Параметр -binary создаст бинарную версию ресурсов в виде *.rcc файла, который можно динамически загружать
в приложении.

E>1. В Qt4 присутствуют несколько библиотек (QtCore, QtGui, QtSql, QtNetwork и т.д.). Для того, чтобы их использовать в своем проекте, необходимо проделать два действия:
E>- определить соответствующий define (например, QT_CORE_LIB для QtCore);
E>- подключить к проекту соответствующую библиотеку.
E>Я думаю, что пользователям MxxRu было бы удобнее поступать так:
E>

E>MxxRu::Cpp::exe_target {
E>  ...
E>  qt = generator MxxRu::Cpp::Qt4.new( self )
E>  qt.core.gui.sql.network
E>  ...
E>

E>За строчкой 'qt.core.gui.sql.network' будут скрываться define QT_CORE_LIB, QT_GUI_LIB, QT_SQL_LIB, QT_NETWORK_LIB и библиотеки QtCore4, QtGui4, QtSql4, QtNetwork4.

Пока добавил в MxxRu::Cpp::Qt4 следующие методы:

lib_qt3support
lib_assistant_client
lib_core
lib_designer
lib_designer_components
lib_gui
lib_help
lib_network
lib_opengl
lib_script
lib_sql
lib_svg
lib_test
lib_xml
lib_xml_patterns
lib_qtmain

Используются так:

  qt = generator MxxRu::Cpp::Qt4.new( self )
  qt.lib_gui
  qt.lib_sql
  qt.lib_qtmain

или так:

  qt = generator MxxRu::Cpp::Qt4.new( self )
  qt.lib_gui.lib_sql.lib_qtmain

Если эти имена не нравятся, еще есть возможность их исправить

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

E>>Пользуется ли кто-нибудь параметром -binary? Для чего этот параметр нужен и что получается при его использовании?

I>Параметр -binary создаст бинарную версию ресурсов в виде *.rcc файла, который можно динамически загружать в приложении.

Похоже, что в Qt4 нужно будет сделать два метода:

qrc2cpp( a_name )
qrc2rcc( a_name )

Использование первого указывает, что из qrc-файла нужно построить cpp-файл. А использование второго указывает на то, что из qrc-файла нужно построить rcc-файл.

Тогда применительно к rcc-файлам возникает следующий вопрос -- куда помещать результирующий rcc-файл? Может быть, укладывать его рядом с целью компиляции? Например, если задано:

MxxRu::Cpp::dll_target {
  target 'plugins/my'

  qt = MxxRu::Cpp::Qt4.new( self )
  qt.qrc2rcc 'my_icons.qrc'
  ...
}

то будет построен файл plugins/my_icons.rcc.

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

E>Используются так:
E>

E>  qt = generator MxxRu::Cpp::Qt4.new( self )
E>  qt.lib_gui
E>  qt.lib_sql
E>  qt.lib_qtmain
E>

E>или так:
E>

E>  qt = generator MxxRu::Cpp::Qt4.new( self )
E>  qt.lib_gui.lib_sql.lib_qtmain
E>

E>Если эти имена не нравятся, еще есть возможность их исправить

Лично мне не нравятся префиксы lib_.

А что, если использовать следующий синтаксис:

  qt = generator MxxRu::Cpp::Qt4.new( self )
  qt.lib( QtGUI, QtSQL, QtMain )

И еще один момент: правильно я понимаю, что нужно линковаться к библиотеке QtMain только, если
это GUI приложение. Если так, то было бы удобнее, если бы MxxRu сам решал нужно линковаться к ней
или нет, основываясь на

screen_mode( ... )

.

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

E>>Если эти имена не нравятся, еще есть возможность их исправить

I>Лично мне не нравятся префиксы lib_.

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

Был еще префикс use_, но мне подумалось, что lib_ как-то лучше отражает смысл того, что к проекту подключается библиотека.

I>А что, если использовать следующий синтаксис:

I>

I>  qt = generator MxxRu::Cpp::Qt4.new( self )
I>  qt.lib( QtGUI, QtSQL, QtMain )
I>

Константы QtGUI, QtSQL и пр. должны быть где-то определены. Писать MxxRu::Cpp::Qt4::QtGUI некошерно. Заставлять программиста делать:

require 'mxx_ru/cpp/qt4'
include MxxRu::Cpp::Qt4

тоже не хочется.

I>И еще один момент: правильно я понимаю, что нужно линковаться к библиотеке QtMain только, если
I>это GUI приложение. Если так, то было бы удобнее, если бы MxxRu сам решал нужно линковаться к ней
I>или нет, основываясь на

I>

screen_mode( ... )

.

Фиг знает. Я вот в примере screen_mode вообще не указывал, только подключил qtmain -- и все скомпилировалось и слинковалось нормально. Получается, что в случае Qt управлять screen_mode вообще не обязательно.

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

E>>1. В Qt4 присутствуют несколько библиотек (QtCore, QtGui, QtSql, QtNetwork и т.д.). Для того, чтобы их использовать в своем проекте, необходимо проделать два действия:
E>>- определить соответствующий define (например, QT_CORE_LIB для QtCore);
E>>- подключить к проекту соответствующую библиотеку.
E>>Я думаю, что пользователям MxxRu было бы удобнее поступать так:
E>>

E>>MxxRu::Cpp::exe_target {
E>>  ...
E>>  qt = generator MxxRu::Cpp::Qt4.new( self )
E>>  qt.core.gui.sql.network
E>>  ...
E>>

E>>За строчкой 'qt.core.gui.sql.network' будут скрываться define QT_CORE_LIB, QT_GUI_LIB, QT_SQL_LIB, QT_NETWORK_LIB и библиотеки QtCore4, QtGui4, QtSql4, QtNetwork4.

E>Пока добавил в MxxRu::Cpp::Qt4 следующие методы:
E>

E>lib_qt3support
E>lib_assistant_client
E>lib_core
E>lib_designer
E>lib_designer_components
E>lib_gui
E>lib_help
E>lib_network
E>lib_opengl
E>lib_script
E>lib_sql
E>lib_svg
E>lib_test
E>lib_xml
E>lib_xml_patterns
E>lib_qtmain
E>

E>Используются так:
E>

E>  qt = generator MxxRu::Cpp::Qt4.new( self )
E>  qt.lib_gui
E>  qt.lib_sql
E>  qt.lib_qtmain
E>

E>или так:
E>

E>  qt = generator MxxRu::Cpp::Qt4.new( self )
E>  qt.lib_gui.lib_sql.lib_qtmain
E>

E>Если эти имена не нравятся, еще есть возможность их исправить

может мое имхо не всем понравится, но мне больше нравится без префикса lib_*
обычно lib добавляется уже автоматом. вы же в makefile пишете -lm а не -llibm
+ под виндой этих префиксов никогда и не было.

если хочется наглядности аля (вот тут мы подрубаем либы (+их конфигурации)), сделайте что то аля

qt.modules += core
qt.modules += gui

или

qt.modules << core
qt.modules << gui

или на крайняк

qt.add_gui
qt.add_sql



Ну а вообще... Что б оценить желание пользователей лучше всего сделать голосавание

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

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

E>>>Если эти имена не нравятся, еще есть возможность их исправить

I>>Лично мне не нравятся префиксы lib_.

E>Мне тоже не очень. Варианты без префикса я не рассматриваю, чтобы не было в будуще пересечений с простыми методами вроде ui.

E>Был еще префикс use_, но мне подумалось, что lib_ как-то лучше отражает смысл того, что к проекту подключается библиотека.

I>>А что, если использовать следующий синтаксис:

I>>

I>>  qt = generator MxxRu::Cpp::Qt4.new( self )
I>>  qt.lib( QtGUI, QtSQL, QtMain )
I>>

E>Константы QtGUI, QtSQL и пр. должны быть где-то определены. Писать MxxRu::Cpp::Qt4::QtGUI некошерно. Заставлять программиста делать:
E>

E>require 'mxx_ru/cpp/qt4'
E>include MxxRu::Cpp::Qt4
E>

E>тоже не хочется.

Сорри что начал отвечать не посмотрев до конца ветку

А мне такой подход очень нравится. привычно и прозрачно.

I>>И еще один момент: правильно я понимаю, что нужно линковаться к библиотеке QtMain только, если
I>>это GUI приложение. Если так, то было бы удобнее, если бы MxxRu сам решал нужно линковаться к ней
I>>или нет, основываясь на

I>>

screen_mode( ... )

.

E>Фиг знает. Я вот в примере screen_mode вообще не указывал, только подключил qtmain -- и все скомпилировалось и слинковалось нормально. Получается, что в случае Qt управлять screen_mode вообще не обязательно.

хм... А что вообще такое QtMain?

здесь и здесь такого модуля нет.

Насколько я понимаю это скрытая либа которая включается qmake автоматически. Зачем же тогда вы её в списке конфигураций включаете если даже в мануале троллей по qmake её нет?

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

I>>>

I>>>  qt = generator MxxRu::Cpp::Qt4.new( self )
I>>>  qt.lib( QtGUI, QtSQL, QtMain )
I>>>

E>>Константы QtGUI, QtSQL и пр. должны быть где-то определены. Писать MxxRu::Cpp::Qt4::QtGUI некошерно. Заставлять программиста делать:
E>>

E>>require 'mxx_ru/cpp/qt4'
E>>include MxxRu::Cpp::Qt4
E>>

E>>тоже не хочется.

DV>Сорри что начал отвечать не посмотрев до конца ветку

DV>А мне такой подход очень нравится. привычно и прозрачно.

Прозрачно это для людей, которые Ruby более-менее знают. А когда человек берет MxxRu и знает о Ruby только то, что это язык такой, то для него использование include будет выглядеть не очень прозрачно и понятно.

У меня был еще вариант:

qt.modules { gui + network + sql }

или

qt.modules { gui; network; sql; }

(т.е. методу modules передается блок кода, который можно запустить на контексте специального объекта, обладающего методами gui, network, sql).

Голосование я могу на RubyForge устроить. Только вот какие варианты туда помещать?

DV>хм... А что вообще такое QtMain?

DV>здесь и здесь такого модуля нет.

DV>Насколько я понимаю это скрытая либа которая включается qmake автоматически. Зачем же тогда вы её в списке конфигураций включаете если даже в мануале троллей по qmake её нет?

Эта библиотека нужна под Windows, поскольку в ней определена функция WinMain.

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

E>Здравствуйте, Denys V., Вы писали:

I>>>>

I>>>>  qt = generator MxxRu::Cpp::Qt4.new( self )
I>>>>  qt.lib( QtGUI, QtSQL, QtMain )
I>>>>

E>>>Константы QtGUI, QtSQL и пр. должны быть где-то определены. Писать MxxRu::Cpp::Qt4::QtGUI некошерно. Заставлять программиста делать:
E>>>

E>>>require 'mxx_ru/cpp/qt4'
E>>>include MxxRu::Cpp::Qt4
E>>>

E>>>тоже не хочется.

DV>>Сорри что начал отвечать не посмотрев до конца ветку

DV>>А мне такой подход очень нравится. привычно и прозрачно.

E>Прозрачно это для людей, которые Ruby более-менее знают. А когда человек берет MxxRu и знает о Ruby только то, что это язык такой, то для него использование include будет выглядеть не очень прозрачно и понятно.

ну блин, как мне кажется, в этом то и преимущество mxx_ru или scons что можно писать скрипты сборки на знакомом, нормальном языке программирования, а не изучать синтаксис cmake, make, m4 или же вообще (да простят меня апологеты "xml anywhere") извращаться с xml-based системами.

Эту проблемму легко обойти. Просто рисуем пример в Tutorial с маленьким примером типового Qt-based приложения. и все кто не хотел разбираться банально его копипастят... вот и все...

E>У меня был еще вариант:
E>

E>qt.modules { gui + network + sql }
E>

E>или
E>

E>qt.modules { gui; network; sql; }
E>

E>(т.е. методу modules передается блок кода, который можно запустить на контексте специального объекта, обладающего методами gui, network, sql).

E>Голосование я могу на RubyForge устроить. Только вот какие варианты туда помещать?

все что нам всем в голову пришли + оставить возможность предложения своего варианта.

ссылку только сюда запостить не забудьте пожалуйста...

Кстати... Если там заводить аккаунт нужно для того что б проголосовать, тогда лучше выбрать rsdn-новский vote... мне так кажется...

DV>>хм... А что вообще такое QtMain?

DV>>здесь и здесь такого модуля нет.

DV>>Насколько я понимаю это скрытая либа которая включается qmake автоматически. Зачем же тогда вы её в списке конфигураций включаете если даже в мануале троллей по qmake её нет?

E>Эта библиотека нужна под Windows, поскольку в ней определена функция WinMain.

Я к тому, что вы её тоже можете неявно линковать...

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

E>>Прозрачно это для людей, которые Ruby более-менее знают. А когда человек берет MxxRu и знает о Ruby только то, что это язык такой, то для него использование include будет выглядеть не очень прозрачно и понятно.

DV>ну блин, как мне кажется, в этом то и преимущество mxx_ru или scons что можно писать скрипты сборки на знакомом, нормальном языке программирования, а не изучать синтаксис cmake, make, m4 или же вообще (да простят меня апологеты "xml anywhere") извращаться с xml-based системами.

Поэтому я и пользуюсь MxxRu. Однако, им пользуются и люди, которые Ruby не знают...

DV>Эту проблемму легко обойти. Просто рисуем пример в Tutorial с маленьким примером типового Qt-based приложения. и все кто не хотел разбираться банально его копипастят... вот и все...

Можно еще сделать так, чтобы конструкция require 'mxx_ru/cpp/qt4' сразу же выполняла include MxxRu::Cpp::Qt4. Тогда пользователю будет еще проще.

E>>Голосование я могу на RubyForge устроить. Только вот какие варианты туда помещать?

DV>все что нам всем в голову пришли + оставить возможность предложения своего варианта.

DV>ссылку только сюда запостить не забудьте пожалуйста...

http://rubyforge.org/survey/survey.php?group_id=1361&amp;survey_id=88

DV>Кстати... Если там заводить аккаунт нужно для того что б проголосовать, тогда лучше выбрать rsdn-новский vote... мне так кажется...

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

E>>Эта библиотека нужна под Windows, поскольку в ней определена функция WinMain.

DV>Я к тому, что вы её тоже можете неявно линковать...

Да, наверное, можно это делать неявно на платформе Windows для exe-шных целей.

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

qt.lib_gui
qt.lib_network
qt.lib_sql

qt.use_gui
qt.use_network
qt.use_sql

qt.lib( QT_GUI, QT_NETWORK, QT_SQL )

имена модулей большими буквами, поскольку это константы.

qt.modules += gui
qt.modules += network
qt.modules += sql

или

qt.modules += QT_GUI
qt.modules += QT_NETWORK
qt.modules += QT_SQL

(этот вариант проще сделать, т.к. QT_* -- это обычные константы, а вот gui/network/sql -- это переменные/методы, которые каким-то образом нужно вводить в текущую область видимости).

qt.modules { gui + network + sql }

или

qt.modules { gui; network; sql }

Вариант с плюсиками лучше, т.к. в нем сложнее ошибиться. ИМХО.

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

E>Пока добавил в MxxRu::Cpp::Qt4 следующие методы:
E>

E>lib_qt3support
E>lib_assistant_client
E>lib_core
...
E>

Переделал. Сейчас есть методы use_module (получает имя одного модуля) и use_modules (получает несколько имен):

require 'mxx_ru/cpp'
require 'mxx_ru/cpp/qt4'

MxxRu::Cpp::exe_target {

  target 'books'
  cpp_sources Dir[ '*.cpp' ]

  qt = generator MxxRu::Cpp::Qt4.new( self )
  qt.use_modules QT_GUI, QT_SQL

  qt.h2moc 'bookwindow.h'
  qt.ui 'bookwindow.ui'

  qt.qrc 'books.qrc'
}

Реализованы константы-идентификаторы: QT_QT3SUPPORT, QT_CORE, QT_DESIGNER, QT_DESIGNER_COMPONENTS, QT_GUI, QT_HELP, QT_NETWORK, QT_OPENGL, QT_SCRIPT, QT_SQL, QT_SVG, QT_TEST, QT_XML, QT_XML_PATTERNS, QT_WEB_KIT, QT_PHONON.

В общем, вот что получилось:

Подключение модулей Qt4 к проекту выполняется с помощью методов use_module/use_modules.

Для подключения ресурсных файлов используются методы:
— qrc2cpp -- генерируется cpp-файл (из a.qrc делается файл qrc_a.cpp), который подключается к списку cpp-ных файлов проекта;
— qrc2rcc -- генерируется rcc-файл (из a.qrc делается файл a.rcc), который располагается рядом с целью проекта.

Содержимое qrc-файлов анализируется и добавляется в список зависимостей для qrc-производных файлов.

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

PS. Текущая версия MxxRu 1.4.7 находится в Subversion-репозитории: http://mxx-ru.rubyforge.org/svn/branches/1.4/
Если кто-то хочет ее пощупать, но не может взять ее из репозиторя, я могу выслать готовый gem-файл.

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

E>По просьбе пользователей добавляю поддержку Qt4 в текущую версию MxxRu 1.4.7.

А теперь, собственно, релиз

Gem-файл версии 1.4.7 доступен на RubyForge: http://rubyforge.org/frs/download.php/48241/Mxx_ru-1.4.7.gem
Так же он доступен через обычную форму gem install/gem update (по крайней мере должен появится в gem-репозитории в течении ближайших часов).

Обновленная документация так же доступна на RubyForge: http://rubyforge.org/docman/view.php/1361/9116/mxx_ru-1.4.7-draft.pdf

Примечания:
1. Из исходников Mxx_ru был выброшен большой объем C-шного кода, который когда-то использовался в тестах. Поэтому результирующий объем gem-файла стал в два раза меньше.
2. В документации описание Qt3 теперь перенесено в приложение A, поскольку появилась родная поддержка Qt4.