hardwarecontrol replacement with dbus-1-tqt #132

Open
deloptes wants to merge 1 commits from feat/new_hwcontrol into master
deloptes commented 1 year ago
Collaborator

@MicheleC
as discussed I push here translated version, but have some issues with the cmake files, so it needs more work to integrate.
I had to rework some minor things (compared to my PoC), because too much stuff is not available when tdelibs is being build and installed.

Signed-off-by: Emanoil Kotsev deloptes@gmail.com

@MicheleC as discussed I push here translated version, but have some issues with the cmake files, so it needs more work to integrate. I had to rework some minor things (compared to my PoC), because too much stuff is not available when tdelibs is being build and installed. Signed-off-by: Emanoil Kotsev <deloptes@gmail.com>
deloptes added 1 commit 1 year ago
33e75d02e9
initial commit for hardwarecontrol replacement
deloptes added 2 commits 1 year ago
cb7b0cf19f
define DBUS_CONNECTION_TIMEOUT outside the function
694ba20bce
remove the library and link everything to the executable
deloptes changed title from WIP: initial commit for hardwarecontrol replacement to WIP: hardwarecontrol replacement with dbus-1-tqt 1 year ago
Poster
Collaborator

I have already forgotten what was the issue with KUniqueApplication. I have tried to replace TQApplication with KUniqueApplication and it fails building as it depends on tdecore headers it can not find.
The problem is I do not know what to do with the cmake so that it builds successfully with KUniqueApplication.

I have already forgotten what was the issue with KUniqueApplication. I have tried to replace TQApplication with KUniqueApplication and it fails building as it depends on tdecore headers it can not find. The problem is I do not know what to do with the cmake so that it builds successfully with KUniqueApplication.
Owner

Hi Emanoil,
the problem with a normal application is that it could be launched twice, and here we are coding a daemon. We need to make sure that if the application is run twice, the second instance detects the first one is running and simply exit doing nothing.
You may not need to use KUniqueApplication for that. A check to see if a dbus trinity service is already registered/running may just do the job. Perhaps you can look at what tdebluez does and if there is something like that there.

Hi Emanoil, the problem with a normal application is that it could be launched twice, and here we are coding a daemon. We need to make sure that if the application is run twice, the second instance detects the first one is running and simply exit doing nothing. You may not need to use KUniqueApplication for that. A check to see if a dbus trinity service is already registered/running may just do the job. Perhaps you can look at what tdebluez does and if there is something like that there.
Poster
Collaborator

I did that already. tdebluez uses KUniqueApplication, but it also runs as the normal user. the dbus daemon is run by root. it's too different pair of shoes. I doubt that it would work because dcop is not running as root anyway, so KUniqueApplication will not register anyway.

I could try something like exit after couple of retries or add a check and exit if the name is already in use.

I'm just sharing information, so that we can think of a solution. I don't remember what the current one is using.

I did that already. tdebluez uses KUniqueApplication, but it also runs as the normal user. the dbus daemon is run by root. it's too different pair of shoes. I doubt that it would work because dcop is not running as root anyway, so KUniqueApplication will not register anyway. I could try something like exit after couple of retries or add a check and exit if the name is already in use. I'm just sharing information, so that we can think of a solution. I don't remember what the current one is using.
Owner

yes, I think we shouldn't use dcop at all here, given we are writing a daemon for dbus 😄

I could try something like exit after couple of retries or add a check and exit if the name is already in use.

Suonds like a solution. If the name is already in use, exit immediately.
If the name is not in used but can't be acquired, perhaps do a few retries and give up in case of continuous error.

@SlavekB any other idea comes to mind?

yes, I think we shouldn't use dcop at all here, given we are writing a daemon for dbus :smile: > I could try something like exit after couple of retries or add a check and exit if the name is already in use. Suonds like a solution. If the name is already in use, exit immediately. If the name is not in used but can't be acquired, perhaps do a few retries and give up in case of continuous error. @SlavekB any other idea comes to mind?
Owner

yes, I think we shouldn't use dcop at all here, given we are writing a daemon for dbus 😄

I could try something like exit after couple of retries or add a check and exit if the name is already in use.

Suonds like a solution. If the name is already in use, exit immediately.
If the name is not in used but can't be acquired, perhaps do a few retries and give up in case of continuous error.

@SlavekB any other idea comes to mind?

Existing code simply try to get the necessary dbus name and if it is not possible (ie the name is already in use), it will end. The dbus server itself takes care of startup and, if necessary, repeated startup, because it tries to activate the appropriate daemon when someone request the service.

> yes, I think we shouldn't use dcop at all here, given we are writing a daemon for dbus :smile: > > > I could try something like exit after couple of retries or add a check and exit if the name is already in use. > > Suonds like a solution. If the name is already in use, exit immediately. > If the name is not in used but can't be acquired, perhaps do a few retries and give up in case of continuous error. > > @SlavekB any other idea comes to mind? Existing code simply try to get the necessary dbus name and if it is not possible (ie the name is already in use), it will end. The dbus server itself takes care of startup and, if necessary, repeated startup, because it tries to activate the appropriate daemon when someone request the service.
Poster
Collaborator

yes, I think we shouldn't use dcop at all here, given we are writing a daemon for dbus 😄

I could try something like exit after couple of retries or add a check and exit if the name is already in use.

Suonds like a solution. If the name is already in use, exit immediately.
If the name is not in used but can't be acquired, perhaps do a few retries and give up in case of continuous error.

@SlavekB any other idea comes to mind?

Existing code simply try to get the necessary dbus name and if it is not possible (ie the name is already in use), it will end. The dbus server itself takes care of startup and, if necessary, repeated startup, because it tries to activate the appropriate daemon when someone request the service.

Thank you @SlavekB,
this means it will wait for dbus connection (probably retry in some time interval). If connection is possible try to obtain the name. If name is already in use exit. I will try to implement it this way.

> > yes, I think we shouldn't use dcop at all here, given we are writing a daemon for dbus :smile: > > > > > I could try something like exit after couple of retries or add a check and exit if the name is already in use. > > > > Suonds like a solution. If the name is already in use, exit immediately. > > If the name is not in used but can't be acquired, perhaps do a few retries and give up in case of continuous error. > > > > @SlavekB any other idea comes to mind? > > Existing code simply try to get the necessary dbus name and if it is not possible (ie the name is already in use), it will end. The dbus server itself takes care of startup and, if necessary, repeated startup, because it tries to activate the appropriate daemon when someone request the service. Thank you @SlavekB, this means it will wait for dbus connection (probably retry in some time interval). If connection is possible try to obtain the name. If name is already in use exit. I will try to implement it this way.
deloptes added 1 commit 1 year ago
c2f392641e
Removed DBusReceiver and moved functionality in HardwareControl
deloptes added the
PR/rfc
label 1 year ago
deloptes changed title from WIP: hardwarecontrol replacement with dbus-1-tqt to hardwarecontrol replacement with dbus-1-tqt 1 year ago
deloptes force-pushed feat/new_hwcontrol from c2f392641e to 813384cbe6 1 year ago
deloptes force-pushed feat/new_hwcontrol from 813384cbe6 to c2804a0792 12 months ago
deloptes force-pushed feat/new_hwcontrol from c2804a0792 to 75c686e277 3 weeks ago
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.