Russian Qt Forum
Март 29, 2024, 15:07 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1] 2   Вниз
  Печать  
Автор Тема: Список сигналов/слотов  (Прочитано 9564 раз)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« : Апрель 10, 2014, 09:30 »

Добрый день

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

Спасибо
Записан
Johnik
Крякер
****
Offline Offline

Сообщений: 339


Просмотр профиля
« Ответ #1 : Апрель 10, 2014, 09:40 »

Список сигналов и слотов:
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
« Последнее редактирование: Апрель 10, 2014, 09:43 от Johnik » Записан
GreatSnake
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2921



Просмотр профиля
« Ответ #2 : Апрель 10, 2014, 11:10 »

в qt 4 никак.
Неправда)
Код
C++ (Qt)
int QObject::receivers ( const char * signal ) const [protected]
Записан

Qt 5.11/4.8.7 (X11/Win)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #3 : Апрель 11, 2014, 11:03 »

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

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

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

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

Спасибо
Записан
kambala
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4724



Просмотр профиля WWW
« Ответ #4 : Апрель 11, 2014, 12:49 »

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

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

Изучением C++ вымощена дорога в Qt.

UTF-8 has been around since 1993 and Unicode 2.0 since 1996; if you have created any 8-bit character content since 1996 in anything other than UTF-8, then I hate you. © Matt Gallagher
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #5 : Апрель 11, 2014, 16:28 »

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

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

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #6 : Апрель 18, 2014, 09:33 »

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

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

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

Решал я своими силами - в Qt прямо готовых средств нет. Чтобы всё правильно работало, пришлось создать собственный реестр редактируемых соединений. В нем прописывается что с чем соединено, кто входы, кто выходы. Этот реестр используется для визуализации и редактирования. Другого пути нет. Собственные структуры Qt для решения этой задачи не годятся, у них нет необходимой функциональности.
« Последнее редактирование: Апрель 18, 2014, 09:36 от Гурман » Записан

2^7-1 == 127, задумайтесь...
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #7 : Апрель 18, 2014, 10:30 »

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

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

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

Это первое что приходит в голову и, возможно, это наивно. Почему? Критикуем, опровергаем
Записан
GreatSnake
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2921



Просмотр профиля
« Ответ #8 : Апрель 18, 2014, 10:36 »

Можно попробовать завязаться на автоматическую систему связывания сигнал/слот:
Цитата: assistant
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>);
Записан

Qt 5.11/4.8.7 (X11/Win)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #9 : Апрель 18, 2014, 11:38 »

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

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

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #10 : Апрель 18, 2014, 12:32 »

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

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

А как это делать конкретно - работа уже конкретного разработчика, за конкретное выполнение которой он деньги получает...
« Последнее редактирование: Апрель 18, 2014, 12:36 от Гурман » Записан

2^7-1 == 127, задумайтесь...
Гурман
Гуру общения
******
Offline Offline

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #11 : Апрель 18, 2014, 12:39 »

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

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

2^7-1 == 127, задумайтесь...
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #12 : Апрель 18, 2014, 16:16 »

А зачем это? Прелесть механизма в том, что ни посылающий, ни принимающий не знают, подключены ли они вообще куда-либо. Если принимающий не подключен - ну он ничего и не принимает.
А надо чтобы сигнал посылался как только коннект установлен и перед тем как разорван. Пример: объект A создает данные (напр QImage) используeмые объектом B. Установка коннекта = B получает имедж, разрыв - B его теряет. Если А изменил имедж - тогда просто испустил сигнал, случай обычного использования.
« Последнее редактирование: Апрель 18, 2014, 16:39 от Igors » Записан
Гурман
Гуру общения
******
Offline Offline

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #13 : Апрель 21, 2014, 14:10 »

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

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

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

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

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

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

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

И вообще - при программировании таких штук лучше думать не только как программист, но и как электронщик.
« Последнее редактирование: Апрель 21, 2014, 14:23 от Гурман » Записан

2^7-1 == 127, задумайтесь...
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #14 : Апрель 21, 2014, 15:39 »

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

..но и как электронщик.
Я и есть бывший с ЕС  Улыбающийся
Записан
Страниц: [1] 2   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.171 секунд. Запросов: 23.