Список сигналов/слотов

[Igors]

Добрый день

Есть QObject (или его потомок). Как получить список его сигналов/слотов (в виде строк) и узнать какие из них сейчвс активны?

Спасибо

[Johnik]

Список сигналов и слотов:
someObject->metaObject()
используя методы:
int methodCount() const;
int methodOffset() const;
int indexOfSignal(const char * signal) const;
int indexOfSlot(const char * slot) const;
QMetaMethod   method(int index) const;

в qt 4 никак.
в qt 5 есть метод:
bool isSignalConnected(const QMetaMethod & signal) const;

или самостоятельно отслеживать коннекты к сигналам connectNotify/disconnectNotify

[GreatSnake]

в qt 4 никак.

Неправда)

Код

C++ (Qt)
int QObject::receivers ( const char * signal ) const [protected]

[Igors]

Тут есть задумки обыграть слот/сигнал по-другому. Пытался обсудить это в др теме - но ничего не вышло, наверное незнакомое название. А суть очень простая: есть объекты и есть связи между ними, выход одного может быть подключен к входу другого. См аттач. Ну и юзверь там чего-то коннектит интерактивно.

Вроде логично задействовать слот/сигнал чтобы иметь это "в общем виде" (не в общем просто тяжело). Каждый нод QObject или потомок. Ну ладно, списки я получу. Теперь мне надо установить какие-то правила:

- какие сигналы и слоты подлежат визуализации
- какие могут быть связаны
- что-то еще

Какие есть мысли/соображения?

Спасибо

[kambala]

можно подсмотреть код соединения сигналов/слотов в креаторе или дизайнере

про визуализацию не понял

[Igors]

можно подсмотреть код соединения сигналов/слотов в креаторе или дизайнере

Или в PythonQt (он это делает)

про визуализацию не понял

Пример. Есть некоторый плагин обрабатывающий изображение. Юзер решает управлять этим эффектом и назначает маску - напр, упрощенно, в пикселях где альфа маски = 0, плагин ничего не делает, где = 1, применяется полностью. Теперь представим что плагинов понимающих эту маску десяток и больше, и сама маска есть результат др. плагина. Как Вы будете управлять/рулить всем этим хозяйством?

[Гурман]

Судя по картинке, речь о разработке системы video composing.

У меня в приложении аналогичная структура, хотя назначение совершенно другое (измерения, обработка сигналов). Каждый плагин, сделанный в виде динамической библиотеки, является "процессором сигнала", имеющим входы и выходы. Каждый вход или выход имеет заданный тип данных. Соединять можно только сигналы (выходы) со слотами (входами) только своего типа. Часть связей устанавливается автоматически при загрузке плагинов, часть может редактировать пользователь. Все вопросы из серии:

- какие сигналы и слоты подлежат визуализации
- какие могут быть связаны

Решал я своими силами - в Qt прямо готовых средств нет. Чтобы всё правильно работало, пришлось создать собственный реестр редактируемых соединений. В нем прописывается что с чем соединено, кто входы, кто выходы. Этот реестр используется для визуализации и редактирования. Другого пути нет. Собственные структуры Qt для решения этой задачи не годятся, у них нет необходимой функциональности.

[Igors]

в Qt прямо готовых средств нет. ...
Другого пути нет. Собственные структуры Qt для решения этой задачи не годятся, у них нет необходимой функциональности.

На использование готовых средств в этом плане никто и не надеялся

Чтобы всё правильно работало, пришлось создать собственный реестр редактируемых соединений. В нем прописывается что с чем соединено, кто входы, кто выходы. Этот реестр используется для визуализации и редактирования.

Вот это я и хотел бы пообсуждать - но пока не вижу энтузиазма. Пока неясно зачем нужно создавать сложную параллельную структуру данных, тем более ноды создаются/удаляются динамически. Почему бы не так:

- что с чем на данный момент соединено узнать можно (детали опускаем)
- если имя слота/сигнала напр кончается "_public", то он подлежит визуализации
- что с чем можно/нельзя соединять.. ну хотя бы  базовый класс с методом типа "SlotCanAcceptSignal", пусть будет большой switch - переживу

Это первое что приходит в голову и, возможно, это наивно. Почему? Критикуем, опровергаем

[GreatSnake]

Можно попробовать завязаться на автоматическую систему связывания сигнал/слот:

void QMetaObject::connectSlotsByName ( QObject * object ) [static]
Searches recursively for all child objects of the given object, and connects matching signals from them to slots of object that follow the following form:

void on_<object name>_<signal name>(<signal parameters>);

[Igors]

Можно попробовать завязаться на автоматическую систему связывания сигнал/слот:

Тут немного по-другому - мне не нужно автоматом все связывать, связки назначает юзер. И возникает такая задачка:

- вот допустим он чего-то связал, как мне вызвать вновь связанный сигнал? Точнее позвать я его могу через invoke... но откуда "взять данные для испускания"? И наоборот, в случае разрыва связки как дать понять принимающему что все, ссылка исчезла? Можно без затей добавить в базовый класс методы напр SlotConnected и SignalDisconnected. Или как-то хитрее?

[Гурман]

Чтобы всё правильно работало, пришлось создать собственный реестр редактируемых соединений. В нем прописывается что с чем соединено, кто входы, кто выходы. Этот реестр используется для визуализации и редактирования.

Вот это я и хотел бы пообсуждать - но пока не вижу энтузиазма.

Я долго (целых 2 дня...) ковырялся и пытался это всё сделать на нативных средствах. Даже где-то на этом форуме ветка была со стенаниями, а вот она. Как видно из ветки, для корректной и удобной работы пришлось бы переписать методы connect и disconnect для QObject. Это уже на грани бреда. Нормальное решение - надо просто создать свой параллельный реестр, который хранит недостающую информацию, и написать свои функции, которые вызывают connect и disconnect для подключаемых вручную объектов, и сохраняют инфу в реестре. И она же используется для отрисовки. Это решение в общем виде.

А как это делать конкретно - работа уже конкретного разработчика, за конкретное выполнение которой он деньги получает...

[Гурман]

в случае разрыва связки как дать понять принимающему что все, ссылка исчезла?

А зачем это? Прелесть механизма в том, что ни посылающий, ни принимающий не знают, подключены ли они вообще куда-либо. Если принимающий не подключен - ну он ничего и не принимает.

[Igors]

А зачем это? Прелесть механизма в том, что ни посылающий, ни принимающий не знают, подключены ли они вообще куда-либо. Если принимающий не подключен - ну он ничего и не принимает.

А надо чтобы сигнал посылался как только коннект установлен и перед тем как разорван. Пример: объект A создает данные (напр QImage) используeмые объектом B. Установка коннекта = B получает имедж, разрыв - B его теряет. Если А изменил имедж - тогда просто испустил сигнал, случай обычного использования.

[Гурман]

А зачем это? Прелесть механизма в том, что ни посылающий, ни принимающий не знают, подключены ли они вообще куда-либо. Если принимающий не подключен - ну он ничего и не принимает.

А надо чтобы сигнал посылался как только коннект установлен и перед тем как разорван. Пример: объект A создает данные (напр QImage) используeмые объектом B. Установка коннекта = B получает имедж, разрыв - B его теряет. Если А изменил имедж - тогда просто испустил сигнал, случай обычного использования.

В первом случае сигнал об установке соединения должен получать А, чтобы испустить имидж через установленное соединение. Синхронизировать надо передачу, а не прием. Хотя какое это имеет значение, если соединение Queued? Если в очереди уже есть имиджи, то как только оно будет установлено, В начнет их получать. А должен просто пихать имиджи в очередь, чтобы они там были. И начать пихать он должен как только будет установлено соединение.

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

То есть, в обоих случаях надо информировать не только В, но и А, причем информировать сначала А, а потом уже В.

И что характерно - в Qt5.x для обоих случаев есть connectNotify и disconnectNotify, оба информируют о соответствующем действии с signal.

Вариант решения - если обязательно информировать В о подключении и отключении соединения, по которому имиджи передаются - ну... тогда можно установить предварительно еще одно соединение между А и В, по которому А будет сигналить в В именно об отключении и подключении сигнала с имиджами.   Только его не надо Queued делать. Сначала устанавливаете это дополнительное соединение без очереди, а потом полезное с очередью - и тогда, после установки полезного, А через дополнительное квакнет в В, что начал посылать имиджи. Или что закончил, потому что произошел разрыв полезного соединения. Только не забыть разорвать дополнительное соединение после того, как будет разорвано полезное.

Если возникает сомнение в таком механизме - так это просто программная реализация давно известного аппаратного решения с раздельными импульсом синхронизации и данными.

И вообще - при программировании таких штук лучше думать не только как программист, но и как электронщик.

[Igors]

В первом случае сигнал об установке соединения должен получать А, чтобы испустить имидж через установленное соединение. Синхронизировать надо передачу, а не прием. Хотя какое это имеет значение, если соединение Queued? Если в очереди уже есть имиджи, то как только оно будет установлено, В начнет их получать. А должен просто пихать имиджи в очередь, чтобы они там были. И начать пихать он должен как только будет установлено соединение.

Получение как бы "единственное", очередей нет. "В" просто использует имедж созданный "A" (если A его создал и установлен коннект) иначе В работает без всяких имеджей. Предлагаемый Вами "строб", на мой взгляд, не решает задачу т.к. все равно нужно лезть в потроха "A" (иначе откуда взять сам имедж для посылки). Ну может это и неизбежно.

..но и как электронщик.

Я и есть бывший с ЕС