WIP: Replace gdbus and GTK with dbus-1-tqt and TDE native notifications #4

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

I am not sure if this is sufficient. I guess there is still some more work to do.

It looks like we can use it with other tools (hardware and other that use notifications)

Thanks Emanoil, will take a look in coming days. Good to move to dbus-1-tqt instead of gdbus

Please see commments below. Several areas need some rework.

Hi Emanoil,
for the async I remember we discussed whether to support async methods in dbusxml2qt3 generation or not. But I don't remember anything specific to glib. Perhaps my memory is wrong, so feel free to correct me if I am wrong.

UPDATE: jsut checked, there was indeed GLib.Async in the examples we discussed in the past.
Question: is it the only way to specify that a method call is asynchronous? Would be good to research if there is a qt-specific way to specify it.

Btw, in the code there are several TODO comments. Are you planning more work there or can those comments be removed?

Btw, in the code there are several TODO comments. Are you planning more work there or can those comments be removed?

Of course if you think this attempt is not in vain and is worth investing time, I can work on the code.

Hi Emanoil,
for the async I remember we discussed whether to support async methods in dbusxml2qt3 generation or not. But I don't remember anything specific to glib. Perhaps my memory is wrong, so feel free to correct me if I am wrong.

UPDATE: jsut checked, there was indeed GLib.Async in the examples we discussed in the past.
Question: is it the only way to specify that a method call is asynchronous? Would be good to research if there is a qt-specific way to specify it.

I don't know Michele, I spent now 15 minutes and couldn't find any useful hint why it is like this. Nor I could find any hint how KDE is doing this.
In the official DBus doc there is reference to GDbus and perhaps it was there in TDE for historic reason.
I remember when working on Bluetooth with KDE5 (Sailfish) that in KF5 it was decided to make all calls Async per default (AFAIR).

We could of course put there whatever we want, but for sure org.freedesktop.DBus.GLib.Async is a valid and well documented specification.

If you ask me I will not touch it.

Btw, in the code there are several TODO comments. Are you planning more work there or can those comments be removed?

Of course if you think this attempt is not in vain and is worth investing time, I can work on the code.

Hi Emanoil,
both Slavek and I like the idea of moving away from gtk dbus and use dbus tqt instead. So it is definitely something worth progressing. In fact initially I thought this was already a completed PR :-)

I don't know Michele, I spent now 15 minutes and couldn't find any useful hint why it is like this. Nor I could find any hint how KDE is doing this.
In the official DBus doc there is reference to GDbus and perhaps it was there in TDE for historic reason.
I remember when working on Bluetooth with KDE5 (Sailfish) that in KF5 it was decided to make all calls Async per default (AFAIR).

We could of course put there whatever we want, but for sure org.freedesktop.DBus.GLib.Async is a valid and well documented specification.

If you ask me I will not touch it.

I did some research too. In the end I think we can keep "org.freedesktop.DBus.GLib.Async" since it does not cause any glib stuff inclusion, it is just a way to mark a method async and dbusxml2qt3 will generate the async call when parsing it.

Let me know when this PR is ready for another review (== TODO are completed). For the time being I will mark it as WIP.

Let me know when this PR is ready for another review (== TODO are completed). For the time being I will mark it as WIP.

Thank you Michele, I Was not sure you will even have a look at it.
I will work further on that. BTW where can I read about HTML in the code - something like <qt>blah</qt>. Thanks

Let me know when this PR is ready for another review (== TODO are completed). For the time being I will mark it as WIP.

Thank you Michele, I Was not sure you will even have a look at it.
I will work further on that. BTW where can I read about HTML in the code - something like <qt>blah</qt>. Thanks

When I use TQLabel I can easily remove the window borders, but then I can not use RichText.
When I use TQTextEdit, I can use RichtText, but don't know how to remove the window borders/frame :)

Let me know when this PR is ready for another review (== TODO are completed). For the time being I will mark it as WIP.

Thank you Michele, I Was not sure you will even have a look at it.
I will work further on that. BTW where can I read about HTML in the code - something like <qt>blah</qt>. Thanks

See TQt3 documentation for TQStyleSheet

See TQt3 documentation for TQStyleSheet

Indeed also TQLabel has setTextFormat method.

@MicheleC
I was wondering, why these notification are not passed to knotify. Is it not possible or not desired?

@deloptes
I can't give a definitive answer for that. I can think of a few reasons:

it was forgotten
the solution is coming from gtk world, so no relationship with knotify in KDE
we don't want to notify the same thing twice, so we either notify through knotify or notify thorugh dbus.

Given point 3), I would keep things as they are, unless @SlavekB has better ideas.

@MicheleC and @SlavekB,
this code definitely catches notifications via DBus, but the standard notification method in TDE is via knotify, so shouldn't this one pass DBus notifications to knotify. To me it makes more sense.
I am not sure if this is possible but otherwise you have as @MicheleC mentioned two notification systems.

Hi Emanoil,
IMO we should avoid double notifications. So the question is whether we need dbus notification at all or not. That is we can catch notifications that come through dbus and we only notify them through knotify, without the additional notification through dbus.

What do you think?

Hi Emanoil,
IMO we should avoid double notifications. So the question is whether we need dbus notification at all or not. That is we can catch notifications that come through dbus and we only notify them through knotify, without the additional notification through dbus.

What do you think?

Yes, this is what I was thinking as well. We could use this or somehow incorporate the interface into knotify and route those notification trough knotify.

Hi Emanoil,
IMO we should avoid double notifications. So the question is whether we need dbus notification at all or not. That is we can catch notifications that come through dbus and we only notify them through knotify, without the additional notification through dbus.

What do you think?

Yes, this is what I was thinking as well. We could use this or somehow incorporate the interface into knotify and route those notification trough knotify.

Great, exactly such a purpose I also assumed – that kdbusnotificaton will receive notifications through DBUS and present them through knotify.

It sounds like an exercise for me.

I will start anothe branch though, based on this PR. Let me know if you have any objections.

Great, exactly such a purpose I also assumed – that kdbusnotificaton will receive notifications through DBUS and present them through knotify.

Great, we are all in sync on this then! 👍

I will start anothe branch though, based on this PR.

@deloptes if the work is based on this PR, IMO you can keep using this branch and rework it if necessary, so we have a consistent history in the comments.

@deloptes
I saw you push a commit recently. Is it ready for new review now? or you need more work first?

@MicheleC no not ready yet, I just did a rebase. It is still on the todo to make it proxy to knotify.
Unfortunately I did not have the time but may be I look into it as now I do not have a notbook to test the BT you are writing in the other mail.

I'll come back to you when ready

Ok, no problem. Thanks for the update.

@MicheleC ,
I need some advise here.
There is knotifyclient which was used in tdebluez.

Why I was left with the impression that it was expected to use dcop to communicate with knotify.

I would use knotifyclient instead of the custom widget I created here.

BR

Hi Emanoil,
knotifyclient seems fine to me, no need to use DCOP calls directly.
As long as avoid double notifications by passing them to knotify, it would be fine.

@MicheleC ,
it seems hard to achive this goal because the class that receives the notification via dbus is not instance of TQ_OBJECT and can not handle knotifyclient.
When I try to use the widget (that now actually shows up and is instance of TQLabel) it also does not handle knotifyclient.
When I try using dcopclient it also does not work, because it does not have TQ_OBJECT

I will put it on hold until some enlightment comes upon me.

Ok, no worries :-)

@MicheleC I spend last two days with this (of course not all the time but few hours :) ), trying to make KNotifyClient work from within the widget, but it doesn't.

I do not understand why

Hi Emanoil,
I suggest we park this PR for the moment and we focus on getting tdebluez up and running first. We can come back to this after that.
What do you think?

Well, while waiting for your feedback on tdebluez, I am looking into it, but I do not see a way how the common notification (knotify) would handle this, because I found out it needs some kind of object running ... and I am not sure but I have seen the notifications popping only from the apps docked in the tray.

So I was hoping we can discuss here and I can get some help. Perhaps I have disabled notifications somehwere in the TDE configuration.

So I was hoping we can discuss here and I can get some help. Perhaps I have disabled notifications somehwere in the TDE configuration.

I see if I can find some time this weekend to have a deeper look, because otherwise I would jsut giving some generic comments that may not be very useful at this point.

@MicheleC and @SlavekB

I do not understand where exactly the TDE own notification is located, but I see a process "knotify [tdeinit]".
I wonder if it is not more appropriate to make this service part of this application.

Also as mentioned I did not find a way to trigger notifications out of the widget, but I see that the current notification methods do not fit the freedesktop notification specs.

So if you have time, think about where we want to go with this.

For now I added animated notification that flows up the right corner of the screen.

gdbus call --session \
--dest=org.freedesktop.Notifications \
--object-path=/org/freedesktop/Notifications \
--method=org.freedesktop.Notifications.Notify \
"TestApp" 1 "" 'Hello world!' \
'This is an example notification.' \
'[]' '{"urgency": <1>}' 5000

     daemon.cpp
     PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${_header}
 )
 make_moc ( notificationsProxy )

  *  Created on: May 11, 2021
  *      Author: emanoil
  *
  * kdbusnotification Copyright (C) 2009 kdbusnotification development team

     delete freedesktopService;
     delete orgService;
     delete rootService;
 //    delete receiver;

  *  Created on: May 11, 2021
  *      Author: emanoil
  *
  * kdbusnotification Copyright (C) 2009 kdbusnotification development team

     OrgNodeService   *orgService;
     FreeDesktopNodeService *freedesktopService;
     NotificationsNodeService *notificationService;
 //    DBusReceiver *receiver;

 https://specifications.freedesktop.org/notification-spec/latest/ar01s09.html
 https://sylvaindurand.org/update-notifications-with-libnotify/
 gdbus call \

 set( NotificationDaemon_HDRS dbusbaseNode.h  introspectableInterface.h  notificationsInterface.h  notificationsNode.h  notificationsProxy.h )
 set( NotificationDaemon_SRCS dbusbaseNode.cpp  introspectableInterface.cpp  notificationsInterface.cpp  notificationsNode.cpp  notificationsProxy.cpp )
 function( make_moc fileinput )

  *  Created on: Feb 7, 2021
  *      Author: emanoil
  *
  * hardwarecontrol Copyright (C) 2009 hardwarecontrol development team

     notificationMap[id]->setIcon(icon);
     notificationMap[id]->setPaletteBackgroundColor(TQt::black);
     notificationMap[id]->setPaletteForegroundColor(TQt::white);
     // FXIME: handle hypertext in the body

  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
  */
 #include <iostream>

     if (!KUniqueApplication::start())
     {
         std::cerr << i18n("notification-daemon-tde is already running.\n").local8Bit();

     {
         KMessageBox::error(NULL,i18n("Can't connect to DBus!"));
         // debug message for testing
         std::cerr << i18n("Can't connect to DBus!\n").local8Bit();

     <method name="Notify">
       <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="notify_daemon_notify_handler"/>
       <annotation name="org.freedesktop.DBus.GLib.Async" value=""/>
       <annotation name="org.freedesktop.DBus.GLib.Async" value="true"/>

     <method name="CloseNotification">
       <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="notify_daemon_close_notification_handler"/>
       <annotation name="org.freedesktop.DBus.GLib.Async" value="true"/>

				`endif( NOT DBUS_FOUND )`


				`##### check for dbus-glib-1`

WIP: Replace gdbus and GTK with dbus-1-tqt and TDE native notifications #4

Reviewers