[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DBUS signals?
[Thread Prev] | [Thread Next]
- Subject: Re: DBUS signals?
- From: Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
- Date: Thu, 26 Sep 2024 04:39:58 +0300
- To: user@xxxxxxxxxxxxxxxxxxxxxx
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 >>> >>>
Re: DBUS signals? | BB <adamnt42@xxxxxxxxx> |
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> |