сигналы и слоты, передача указателя на мой объект Опции

[ieroglif]

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

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

на данный момент реализация модульного интерфейса такая:

#ifndef IMODULE_H
#define IMODULE_H

#include "commands.h"
#include <QtPlugin>

class iModule : public QObject
{
public:
    virtual ~iModule() {}
    virtual void moduleStart(iModule*) = 0;
    virtual void moduleRun() = 0;
signals:
    void sendCommand( CMDS::Command, iModule* );
    void sendData( const QString );
public slots:
    virtual void getCommand( CMDS::Command, iModule* ) = 0;
    virtual void getData(const QString) = 0;
};

Q_DECLARE_INTERFACE(iModule,"ieroglif.module/1.0");


#endif // IMODULE_H

и на данный момент алгоритм вижу следующий:

1. загружаются модули
2. при загрузке они соединяют слоты сигналы sendCommand - getCommand с ядром в обе стороны. Ядро же на какие-то комманды (типа выход) реагирует, а вообще принятый сигнал перекидывает всем модулям, которые уже разбирают на какие комманды и как им реагировать.
3. модуль "нарды" при запуске кидае комманду "добавить элемент в трей-меню".
4. на него реагирует модуль "трей" (если присутсвует, конечно) и коннектит слоты-сигналы с объектом, который пришёл в сигнале.
5. модуль "трей" по новому коннекту кидает что-то типа "готов" и модуль "нарды" закидывает туда готовый QAction* для меню.
6. модуль "трей" разрывает слот-сигнал с "нардами".

тем самым я добиваюсь независимости модулей друг от друга. "нарды" знают, что надо отправить запрос ядру на добавления меню, и что если кто-то им потом ответит по другому слоту, кинуть туда элемент меню, а "трей" знает, что если кто-то у него попросит место в трее, то ему пофик кто это - лишь бы кинули потом элемент меню.

в целом мне схема нравится, но буду рад другим идеям.

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

буду рад ответу сюда, или по координатам
ася 133733457
скайп ieroglif.ru
jabber: ieroglif@jabber.myau.su

[Litkevich Yuriy]

как через слот-сигнал передать указатель на любой объект.

передавай указатель на QObject, соответственно все объекты должны быть его наследниками. Это достаточно универсально.

Поповоду модобного симбиоза я долго думал, но пока в голове ничего, мне нужно было для "Главного окна" приложения, в котором неготорые возможности становятся доступными посредством плагинов.
Была мысль обсудить это дело на форуме, и придумать некий "стандарт" на интерфейс. Но так я и не созрел к этому.

[ieroglif]

ну типа эта =)
указатель на QObject - это уже приятно, потом просто приводить к нужному типу?
если передаю QAction, то QAction object = (QAction)recive_object; ?
а если у меня мой "трей" представления не имеет кто у него попросит добавить элемент? как мне приводить тогда объекты? мне же надо ещё и слоты-сигналы соединять..
или я туплю и всё намного проще - я соединяю слоты-сигналы по интерфесу модуля, а там через get/sendData(QObject*) перекидываю что хочу? =) мда.. по ходу действительно туплю.. но тоже полезно иногда =)

а обсуждение "стандарта на интерфейс" я как раз и поднимаю и приветсвую =)
моё предложение описано выше =)

[Litkevich Yuriy]

указатель на QObject - это уже приятно, потом просто приводить к нужному типу?
если передаю QAction, то QAction object = (QAction)recive_object; ?

приведение типов в Qt осушествляется не Си'шным способом, а вот так:

VerType *var = qobject_cast<VerType *>(sourcevar);

хотя можно и Си++'ным, через dynamic_cast

[SABROG]

В QObject'е достаточно информации. Из него ты можешь узнать является ли объект окном, название класса окна (QPushButton, QTreeWidget, QDockWidget, QLabel и т.д.). Список методов, слотов и сигналов, все параметры.

[Litkevich Yuriy]

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

[Litkevich Yuriy]

как через слот-сигнал передать указатель на любой объект.

А может тебе и не надо передавать указатель?
Ведь при срабатывании слота ты всегда можешь узнать кто послал сигнал в него используя QObject * QObject::sender () const [protected] :

Button *clickedButton = qobject_cast<Button *>(sender());

взято из примера Калькулятор

Сейчас наобум прошвырнулся по своим интернет-закладкам и не нашел их сайт

нашел!
qmdilib

[ieroglif]

вот на тему сендера - это грамотный ход.
тогда модули станут ещё более независимы =)
а ещё у меня была мысль что бы модули регистрировали в ядре комманды, которые их интересуют, что бы ядро рассылало приходящие сигналы только нужным модулям..
но немного подумав, решил, что это только бОльший геморой, и ещё не одназначен прирост производительности.
ну явно же не будет в программе лям модулей (да и то лям слотов-сигналов, по утверждению троллей, пройдёт за секунду, так что..)
а количество "рассылок" на единицу больше количества модулей в системе..

[kuler]

а сигналы и слоты наследуются?

[AD]

In Qt, we have an alternative to the callback technique: We use signals and slots. A signal is emitted when a particular event occurs. Qt's widgets have many predefined signals, but we can always subclass widgets to add our own signals to them. A slot is a function that is called in response to a particular signal. Qt's widgets have many pre-defined slots, but it is common practice to subclass widgets and add your own slots so that you can handle the signals that you are interested in

Вот эта фраза

A slot is a function that is called in response to a particular signal

подразумевает, что слот - эта функция, значит, обладает всеми ее свойствами и наследуется. На счет сигналов, полагаю, что тоже наследуются. Иначе в этом механизме нет особого смысла.