Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Не перестаю узнавать все новые и новые грани использования Qt :)
Вообще насколько я понял D-Bus это не только и не столько Qt, сколько отдельный механизм межпроцессного взаимодействия.
Поэтому собственно
Была бы полезна отдельная статья чисто по D-Bus, без привязки к языку.
Поэтому собственно
Пытаться понять логику работы с DBus по доке Qt — дело неблагодарное.
Была бы полезна отдельная статья чисто по D-Bus, без привязки к языку.
кто-то может обьяснить обстоятельство с «Бонус-левелом»? можно пробовать предположить, что `pong` удаляется по выходу из области видимости, но ведь рано ему удаляться(выход будет только по завершению приложения).
Точно не в этом. Можно сделать что в подобном духе:
Но вылет всеравно будет.
Pong * pong = new Pong();
if( ! QDBusConnection::sessionBus().registerObject("/", pong)){
Но вылет всеравно будет.
я понимаю, что это глупо, но что будет, если
Pong * pong = new Pong(new QObject);
?
Pong * pong = new Pong(new QObject);
?
Шаманство — не падает. Но интерфейс не регистрируется
я думаю, тут не шаманство, а наше полное непонимание концепции Qt.
вот тут почитай, как все устроено. довольно просто описано. 15 минут: голова в норме
когда почитаешь, поймешь, что родительский объект обязателен. хотя да, товарищи могли сделать более изящно и создать его сами, если он — nullptr. вообще говоря, стоит перечитать пример, с которого ты списал свой. ты далеко не все списал и далеко не все понял, из того, что там было написано. я вот только начал читать и многие вещи становятся очевидными.
вот тут почитай, как все устроено. довольно просто описано. 15 минут: голова в норме
когда почитаешь, поймешь, что родительский объект обязателен. хотя да, товарищи могли сделать более изящно и создать его сами, если он — nullptr. вообще говоря, стоит перечитать пример, с которого ты списал свой. ты далеко не все списал и далеко не все понял, из того, что там было написано. я вот только начал читать и многие вещи становятся очевидными.
Эээ, ссылки нет.
Дело в том, что сам QAbstractDbusAdaptor — наследник QObjetc предполагать, что для нужен родитель очень странно. Тем более, если взять вариант, наследующийся напрямую от Qobject, объявить его итерфейсом, то все заработает и не будет вылетов.
Дело в том, что сам QAbstractDbusAdaptor — наследник QObjetc предполагать, что для нужен родитель очень странно. Тем более, если взять вариант, наследующийся напрямую от Qobject, объявить его итерфейсом, то все заработает и не будет вылетов.
да. увидел. вот ссылка
qt.gitorious.org/qt/qt/blobs/00fa3f364fe9657317cb14191167aa9991c1758e/src/dbus/qdbusabstractadaptor.cpp
(странно, но у меня совсем не работают теги разметки)
qt.gitorious.org/qt/qt/blobs/00fa3f364fe9657317cb14191167aa9991c1758e/src/dbus/qdbusabstractadaptor.cpp
(странно, но у меня совсем не работают теги разметки)
Угу, понял, почитаю чуть позже, может пойму чего они хотели добиться.
И да, мне до чертиков любопытно знать, что ты понял и вызнал.
И да, мне до чертиков любопытно знать, что ты понял и вызнал.
ну, как минимум, сразу бросается в глаза:
explicit QAbstractButton(QWidget* parent=0); // это выбрал из рандомного файла. помню этот концепт наизусть.
QDBusAbstractAdaptor(QObject *parent);
казалось бы, не такая уж и странная вещь, но у Qt-шников довольно тсрогий стиль. и если в первом случае мы видим, что наличие дефолтного параметра как-бы намекает, что родитель вполне себе может отсутствовать, то во втором — родитель строго нужен.
то, что указатель может быть nullptr — минус конструкции языка и недоработка, собственно программистов.
лень им было ассерт поставить и выбросить логическую ошибку при nullptr?
свой создавать, по факту, плохо: им пришлось бы думать, как после него память освободить. хотя есть, конечно, обходные пути, типа создания совсем уж корневого статического объекта.
именно это отличие заставило меня начать вчитываться в пример. что я там вычитал, могу рассказать завтра. если нужно, в личку(сегодня поезд, потому чтение я отложил пока).
explicit QAbstractButton(QWidget* parent=0); // это выбрал из рандомного файла. помню этот концепт наизусть.
QDBusAbstractAdaptor(QObject *parent);
казалось бы, не такая уж и странная вещь, но у Qt-шников довольно тсрогий стиль. и если в первом случае мы видим, что наличие дефолтного параметра как-бы намекает, что родитель вполне себе может отсутствовать, то во втором — родитель строго нужен.
то, что указатель может быть nullptr — минус конструкции языка и недоработка, собственно программистов.
лень им было ассерт поставить и выбросить логическую ошибку при nullptr?
свой создавать, по факту, плохо: им пришлось бы думать, как после него память освободить. хотя есть, конечно, обходные пути, типа создания совсем уж корневого статического объекта.
именно это отличие заставило меня начать вчитываться в пример. что я там вычитал, могу рассказать завтра. если нужно, в личку(сегодня поезд, потому чтение я отложил пока).
М-да, подстава. Привык что родитель это необязательный элемент, а где не так — так сразу и не припомню. Да, надо будет исходники почитать.
Ну можно и не в личку. Чистого пути.
Ну можно и не в личку. Чистого пути.
спасибо
Прошу прощения сразу за 2 вещи:
— как-то затянулась моя интеграция в среду после приезда и я забыл отписаться сюда
— понимание примеров было все-таки полным (чего все-таки не скажешь про документацию. о ней как раз будет идти речь)
как я уже написал ранее, на мысль меня натолкнуло отсутствие знаения аргумента по-умолчанию. и это оказалось вполне обоснованным. читая документацию, буквально в первом-же абзаце я наткнулся на следующую мысль:
The QDBusAbstractAdaptor class is the starting point for all objects intending to provide interfaces to the external world using D-Bus. This is accomplished by ATTACHING a one or more classes derived from QDBusAbstractAdaptor TO A NORMAL QObject AND THEN REGISTERING THAT QObject with QDBusConnection::registerObject. QDBusAbstractAdaptor objects are intended to be light-weight wrappers, mostly just relaying calls into the real object (its parent) and the signals from it.
собственно, заглавными буквами я обозначил нужную мысль, которая была упущена тобой.
вот еще несколько мыслей об использовании наследников QDbusAbstractAdaptor:
— (могу ошибаться в переводе) нельзя создать больше одного экземпляра одного класса
— каждый экземпляр должен создаваться с помощью оператора new
— ни один экземпляр не должен быть удален пользователем. они удалятся автоматически при удалении родительского обьекта
остальное буду читать как-нибудь позже, когда будет больше свободного времени.
сразу прошу прощения за отсутствие разметки и/или наличие опечаток в тексте.
— как-то затянулась моя интеграция в среду после приезда и я забыл отписаться сюда
— понимание примеров было все-таки полным (чего все-таки не скажешь про документацию. о ней как раз будет идти речь)
как я уже написал ранее, на мысль меня натолкнуло отсутствие знаения аргумента по-умолчанию. и это оказалось вполне обоснованным. читая документацию, буквально в первом-же абзаце я наткнулся на следующую мысль:
The QDBusAbstractAdaptor class is the starting point for all objects intending to provide interfaces to the external world using D-Bus. This is accomplished by ATTACHING a one or more classes derived from QDBusAbstractAdaptor TO A NORMAL QObject AND THEN REGISTERING THAT QObject with QDBusConnection::registerObject. QDBusAbstractAdaptor objects are intended to be light-weight wrappers, mostly just relaying calls into the real object (its parent) and the signals from it.
собственно, заглавными буквами я обозначил нужную мысль, которая была упущена тобой.
вот еще несколько мыслей об использовании наследников QDbusAbstractAdaptor:
— (могу ошибаться в переводе) нельзя создать больше одного экземпляра одного класса
— каждый экземпляр должен создаваться с помощью оператора new
— ни один экземпляр не должен быть удален пользователем. они удалятся автоматически при удалении родительского обьекта
остальное буду читать как-нибудь позже, когда будет больше свободного времени.
сразу прошу прощения за отсутствие разметки и/или наличие опечаток в тексте.
Если заметить, что родительский элемент обязателен, то последнее два очевидно — родитель сам удалит своего потомка. Первый пункт тоже очевиден — иначе возникнет траблы при подключении к D-Bus, ибо только один интерфейс может быть расположен по тому же пути. Сейчас разбираюсь в коде, похоже это тупо патерн Адаптер для связки Qt-мира и D-bus-мира
не согласен насчет очевидности удаления: с точки зрения логики(да и в коде Qt есть на это намеки, хотя я сильно не вникал), если ты удаляешь обьект, он автоматически вытирает запись о себе в родительском обьекте и удаляет всех своих потомков(порядок может быть обратным).
первый же пункт становится очевидным лишь после понимания того, что система использует Q_CLASSINFO для идентификации обьекта.
первый же пункт становится очевидным лишь после понимания того, что система использует Q_CLASSINFO для идентификации обьекта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
QtDbus — тьма, покрытая тайною. Часть 1