Организация скриптов в приложении

[Igors]

Ну так у вас вызовется метод объекта вашего врапера, при обращении к prop1. В нем и создавайте динамически объект.

Это если пропердия заряжена с помощью py_get_ и py_set_. Но это не очень выгодно, поэтому я просто наследуюсь от QObject и делаю setProperty. Все норм, пытон ее видит, кстати можно и из самого пытона

Код:

prj.setProperty("myProp", 1)
print prj.myProp   # печатает 1

Но так где взять враппер? 

[Old]

Вы используете объект QObject только для хранения свойств?
Вы можете описать свой класс-наследник QObject и задать все необходимые propery с геттерами/сеттерами, которые и будут использоваться из питона.
См.: http://doc.crossplatform.ru/qt/4.6.x/properties.html

[Igors]

Вы используете объект QObject только для хранения свойств?
Вы можете описать свой класс-наследник QObject и задать все необходимые propery с геттерами/сеттерами, которые и будут использоваться из питона.
См.: http://doc.crossplatform.ru/qt/4.6.x/properties.html

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

[Old]

Мне же хочется "опубликовать" в пытоне только проперди объектов которые известны в общем виде

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

[Igors]

Внутри приложения примерно так

Код

C++ (Qt)
class SomeAppClass {
 ... // конечно тут есть члены, методы, но они не для юзера
 
 ChannelList mChannelList;    // а вот это для него
};
 
// использование
Channel * ch = mChannelList.GetChannelById(ID_COLOR);  // найти канал по Id
if (!ch) return;
string name = ch->GetName();   // имя канала, напр "Color"
ARGB val = ch->GetValue(frameTime);   // значение
Channel * child = ch->GetChild(0);    // возможен child
и.т.д.
 

Поэтому городить сотни геттеров/сеттеров нет смысла

[Old]

Вопрос один: как это все соотносится с вопросом о динамическом создании объекта при чтении свойства?

[Igors]

Вопрос один: как это все соотносится с вопросом о динамическом создании объекта при чтении свойства?

Пользователь может написать напр такой скрипт

Код:

obj.Color.red = 255

Но может и не трогать Color или вообще заняться obj2 оставив obj без внимания. Поэтому заряжать в пытон все-все проперди статически (любая может использоваться) совершенно глупо

[Old]

Пользователь может написать напр такой скрипт

Код:

obj.Color.red = 255

Но может и не трогать Color или вообще заняться obj2 оставив obj без внимания. Поэтому заряжать в пытон все-все проперди статически (любая может использоваться) совершенно глупо

Что значит глупо? Это обязательное условие. Все действия для вашего объекта должны быть полностью за декларированы в контексте скрипта. Абсолютно все.
То что за вас большую часть работы делает Qt + PythonQt, вовсе не означает что эта работа не делается.

Будет пользователь сейчас что-то вызывать или он это сделает завтра не важно, все должно быть описано перед использованием в скрипте. Поэтому, если пользователь сейчас (или через 10 лет) захочет написать obj.Color.red = 255, то сеттер для такого присвоения должен быть. Его вы можете написать сами, а можете оставить на совести Qt с PythonQt.

Теперь по поводу примера:

Код

C++ (Qt)
Channel * ch = mChannelList.GetChannelById(ID_COLOR);  // найти канал по Id
if (!ch) return;
string name = ch->GetName();   // имя канала, напр "Color"
ARGB val = ch->GetValue(frameTime);   // значение
Channel * child = ch->GetChild(0);    // возможен child
 

Если объект Channel наследник QObject, то нам достаточно добавить описание необходимых свойст и они автоматом станут доступны из питона:

Код

C++ (Qt)
class Channel : public QObject
{
    Q_OBJECT
    Q_PROPERTY( QString name READ GetName WRITE SetName )
    Q_PROPERTY( QColor value READ GetValue WRITE SetValue )
    ...
 

Больше никаких телодвижений не понадобиться, все остальное сделает Qt с PythonQt.

А если Channel не наследник, то вам все равно придется все расписывать руками, каждый сеттер и каждый геттер, не зависимо от того, будет это PythonQt или boost::python.

[Igors]

Будет пользователь сейчас что-то вызывать или он это сделает завтра не важно, все должно быть описано перед использованием в скрипте. Поэтому, если пользователь сейчас (или через 10 лет) захочет написать obj.Color.red = 255, то сеттер для такого присвоения должен быть.

Нет, можно делать геттеры/сеттеры динамически, только когда они юзаются в пытоне. Вот фрагмент работающего примера

Код

C++ (Qt)
void MyQtQObjectWrappedCB( QObject * object )
{
	CPyObject * py = dynamic_cast <CPyObject *> (object);
	if (!py || py->mWrapped) return;
	py->mWrapped = true;    // есть анодное!
  	py->setProperty("dynaProp", QVariant(1.0));
 
	printf("wrapped %p\n", py);
}
...
PythonQt::self()->setQObjectWrappedCallback(MyQtQObjectWrappedCB);		
 

Если объект Channel наследник QObject, то нам достаточно добавить описание необходимых свойст и они автоматом станут доступны из питона:

Конечно будут, но такой "механический" перенос ничего не дает, пользователю нужно не "внутреннее устройство", а упрощенный синтаксис. Перелопатить все классы чтобы его добавить - глупо, нужно использовать механизм dynamic properties, для него все есть

[Old]

Нет, можно делать геттеры/сеттеры динамически, только когда они юзаются в пытоне. Вот фрагмент работающего примера

Где вы здесь видите динамические геттеры/сеттеры? Здесь вы создаете новое свойство, а геттеры/сеттеры для него сделает Qt, точнее ее система свойств. О чем я и писал выше.

Пример, по крайней мере, странный. Что это дает не понятно. Объект уже существует, у него или есть какие-то свойства или их нет. Почему они должный появляться или исчезать не понятно. Вот есть точка, у нее есть два свойства - координаты x и y. Они есть всегда.

[Igors]

Пример, по крайней мере, странный. Что это дает не понятно. Объект уже существует, у него или есть какие-то свойства или их нет. Почему они должный появляться или исчезать не понятно. Вот есть точка, у нее есть два свойства - координаты x и y. Они есть всегда.

Не всегда

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

Да и не в этом даже дело. Просто расписать "все что (может быть) нужно пытону" - уже работа на неделю. Отловить все места где вместо одних параметров могут быть другие - еще неделя.

Хорошо, а как насчет пресловутой "архитектуры"? Как это должно выглядеть с точки зрения приложения. где хранить данные доступные из скриптов?

1) Прямо в самих классах и пытон их меняет. Не верится, как-то стремно
2) Приклеить к классам что-то типа CPyObject *
3) Мапа <объект *, CPyObject *>
4) Еще ходы?

Спасибо
 

[Old]

Не всегда

Всегда.

Хорошо, а как насчет пресловутой "архитектуры"? Как это должно выглядеть с точки зрения приложения. где хранить данные доступные из скриптов?

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