[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DBUS signals?


DBus reminds me of Windows registry. And I don't mean anything good about
that. I wonder what was the practical problem of using sockets, pipes,
files and system signals. And did this solve any of the problems.

Jussi

On Thu, Sep 26, 2024 at 4:16 AM Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
wrote:

> Meh, didn't change anything.
>
> hDBUS = New DBusSignal(DBus.System, "org.freedesktop.login1.Manager",
> "/org/freedesktop/login1", "PrepareForShutdown", True) As "DBusSignal"
>
> I do not understand why I would need to provide all that. What is the
> point? Why so complicated? There is already an interface for the object,
> thus the object should not be required.
>
> The event declaration already has "Signal as String". And I also want to
> catch "PrepareForSleep".
> Public Sub DBusSignal_Signal(Signal As String, Arguments As Variant[])
>
>
> Jussi
>
>
>
> On Thu, Sep 26, 2024 at 4:04 AM Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
> wrote:
>
>> Umm.. no you are right.
>> I read it on here...  https://gambaswiki.org/wiki/doc/dbus
>> Completely different set of arguments.
>>
>>
>> Jussi
>>
>> On Thu, Sep 26, 2024 at 3:56 AM Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
>> wrote:
>>
>>> Now there's a trap! AFAICS
>>>>
>>>> <*Every*> tells the runtime what signals to look for. If it's not set
>>>> then you should only get signals (of some name) that are addressed to you.
>>>> Now, the system bus signals mostly are not addressed to a particular
>>>> subscriber and to get them you have to look for them.
>>>>
>>> OK, I tested. Did not work.
>>>
>>>
>>>> <*object*> is the *DBus object* not an object in your program, nor is
>>>> it the Gambas DBusObject. For example, I have a program that updates race
>>>> events from the internet on a scheduled poll basis. It uses separate *DBUS
>>>> objects* for every race at each meeting on the day and when it gets an
>>>> update it raises a DBus event on *that object only*. That way I dont
>>>> need to process all the races for the day when I get an update signal, only
>>>> that race. Having said that, in general, DBUS servers don't use objects and
>>>> just use a general interface that is used by all server objects. Have a
>>>> look at the screenshot. Its from QDBusViewer. See how its different from
>>>> "most" DBus server lists.
>>>>
>>> Again, I'm using DBusSignal. It does not take any objects as an argument
>>> nor does it return any. There are only three arguments; bus, interface and
>>> every.
>>>
>>>
>>>> <*signal*> might be known in your project, but you have to tell the *Gambas
>>>> DBus component* itself what *signal on the other side* you are
>>>> interested in. The signal in this instance is not a Gambas event it is the
>>>> name of a signal on the DBus bus. The gb.dbus component is the thing that
>>>> raises an *event* inside your project, i.e. signal name <> event name.
>>>>
>>> Again, no. The signal is an argument of the Signal event. See DBusSignal
>>> class documentation.
>>>
>>>
>>> Jussi
>>>
>>>

Follow-Ups:
Re: DBUS signals?BB <adamnt42@xxxxxxxxx>
References:
DBUS signals?Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
Re: DBUS signals?BB <adamnt42@xxxxxxxxx>
Re: DBUS signals?Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
Re: DBUS signals?BB <adamnt42@xxxxxxxxx>
Re: DBUS signals?Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
Re: DBUS signals?Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
Re: DBUS signals?Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>