Re: DBUS signals?

[Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>]

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
>
>